4 ms·

Re: Dependencies - There are at least two well known, well supported, rock solid ways of managing dependencies that are in very common use in the python deploym

Re: Dependencies - There are at least two well known, well supported, rock solid ways of managing dependencies that are in very common use in the python deployment world. Some combination of requirements.txt (which lets you dial in, with great precision, each of the libraries you need, and is trivially created in < 50msec with "pip freeze") 1. Containers - That's it. You control everything in it. 2. virtualenv - Every environment comes their own version of python and their own set of packages and versions of those packages. Add virtualenvwrappers and you can create/switch trivially between them. It's been at least 2 years since I've run into a issue with python and dependencies that wasn't solved by both of those approaches.

skohan 6y ago
I mean I think you can get a workable setup, it just seems really clunky to me. Like you cobble together some solution out of pip, docker, venv, and if you're jumping into someone else's project you better hope they documented it (wait I have to call `source` on which file?). It's a far cry from being able to download any git repo and call `cargo build`/`cargo run` or `npm install`/`npm run` with confidence that it's just going to work.
- pyrale 6y ago
  To be honest, I do expect to find a project provided with a pipenv/poetry setup, just like I would expect a haskell codebase to have a cabal/stack setup, and a java codebase to have a maven/gradle setup. It is true that most recent languages ship with these from day 1, but ecosystems rarely lack this kind of stuff. I mean, even my vim has a package manager nowadays. As for whether you want to salvage old code that isn't provided with package management, it's up to you. But you would have this kind of problem with any old, unmaintained codebase.
- ghshephard 6y ago
  I guess part of it depends on the teams/people you work with. I agree - that it would be nice in the python world if we all just agreed, "virtualenv + requirements.txt - Done." - Instead, as you noted, the python ecosystem has split into venv, pyenv, pipenv, Poetry, Conda, .... Where I work - life is simple. You build your project in a virtualenv so it only has the libraries it needs, generate a clean requirements.txt, check it into git with a requirements.txt - everyone can run it, and, because we have day-1 onboarding to teach everyone virtualenv/virtualenvwrapper - the first thing a person does before installing the application is mkvirtualenv. I see a lot of references to Poetry here - but I've never been able to interest any of our senior developers into looking at it - they are pretty happy with our existing system.
sellyme 6y ago
> It's been at least 2 years since I've run into a issue with python and dependencies that wasn't solved by both of those approaches. The problem is that this leaves us with 2 years of documentation that's reliable and addresses easily-solved problems, and 28 years of everything else that will confuse anyone new to the language. Not ideal when accessibility is one of the language's primary selling points. One of the major problems with fixing design choices or odd behaviours in software is that all of the old threads and posts don't just disappear, and people are now going to be lead down paths that are not only so convoluted and ridiculous that they were eventually changed, but often paths that don't even work any more. It's very very tough to fix that problem retroactively.

skohan 6y ago

I mean I think you can get a workable setup, it just seems really clunky to me. Like you cobble together some solution out of pip, docker, venv, and if you're jumping into someone else's project you better hope they documented it (wait I have to call `source` on which file?). It's a far cry from being able to download any git repo and call `cargo build`/`cargo run` or `npm install`/`npm run` with confidence that it's just going to work.

pyrale 6y ago
To be honest, I do expect to find a project provided with a pipenv/poetry setup, just like I would expect a haskell codebase to have a cabal/stack setup, and a java codebase to have a maven/gradle setup. It is true that most recent languages ship with these from day 1, but ecosystems rarely lack this kind of stuff. I mean, even my vim has a package manager nowadays. As for whether you want to salvage old code that isn't provided with package management, it's up to you. But you would have this kind of problem with any old, unmaintained codebase.
ghshephard 6y ago
I guess part of it depends on the teams/people you work with. I agree - that it would be nice in the python world if we all just agreed, "virtualenv + requirements.txt - Done." - Instead, as you noted, the python ecosystem has split into venv, pyenv, pipenv, Poetry, Conda, .... Where I work - life is simple. You build your project in a virtualenv so it only has the libraries it needs, generate a clean requirements.txt, check it into git with a requirements.txt - everyone can run it, and, because we have day-1 onboarding to teach everyone virtualenv/virtualenvwrapper - the first thing a person does before installing the application is mkvirtualenv. I see a lot of references to Poetry here - but I've never been able to interest any of our senior developers into looking at it - they are pretty happy with our existing system.

sellyme 6y ago

> It's been at least 2 years since I've run into a issue with python and dependencies that wasn't solved by both of those approaches. The problem is that this leaves us with 2 years of documentation that's reliable and addresses easily-solved problems, and 28 years of everything else that will confuse anyone new to the language. Not ideal when accessibility is one of the language's primary selling points. One of the major problems with fixing design choices or odd behaviours in software is that all of the old threads and posts don't just disappear, and people are now going to be lead down paths that are not only so convoluted and ridiculous that they were eventually changed, but often paths that don't even work any more. It's very very tough to fix that problem retroactively.