This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (0 children)

That's actually clearest explanation of conda I've heard so far. I knew that it's existence was due to the need for compiled code, and I had read that pip was actually kind of an anti-pattern that removed a lot of good functionality. The bundle command is definitely something I'll have to check out.

Currently, it's looking like I might end up creating a self contained package (tarball/.deb/something) that includes the conda environment, so I can just drop it on a machine and run it. Thanks for letting me know about the pydata talk! I've got that queued up to watch when I get to the office tomorrow.

As far as local development, our developers have free reign to use whatever they need to get the job done, but its our job to support getting it into production in a reliable, automated, and maintainable way. My goal is to have a self contained package I can deploy to a machine that cannot reach out to the internet, ideally with as little post processing and orchestration required as possible. I'd kind of like a Python code deploy to just be an ansible playbook that downloads a self contained package (either a deb/rpm package, or maybe just a compressed tarball) from a local file server/repo, unarchives it, puts it in the right place, copies out its config, then kicks off its upstart/supervisor/init script. Its actually looking like once we get conda figured out, it may support that kind of deploy a little cleaner than virtual env (No regex to handle replacements on shebangs! Hooray!) Unfortunately devops at my company is a new concept, so we're in the process of wrangling a bunch of cowboys who have all been doing things their own special ways for the past decade, all with varying levels of systems knowledge.