4 ms·

libraries and apps _should_ get different treatment. A library often has to coexist with other unknown code (open world assumption), an application you're contr

by rtpg 8y ago

libraries and apps _should_ get different treatment. A library often has to coexist with other unknown code (open world assumption), an application you're controlling is effectively existing in one specific universe: the one you define (closed world assumption). You wouldn't write your application to support 5 versions of Django, but you _probably_ would do so for a library. That said, I do basically agree about `pip` existing already. We could have built a tool to manipulate `requirements.txt` files instead of introducing another format and a toolchain that is _much_ slower and brittler. Though ultimately at this point Python packaging woes feel like they are at a much lower level (the fact that libraries end up being "installed" mean that preparing all your dependencies to go out to multiple servers is a mess).

pseudalopex 8y ago
An internal application can exist in one specific universe. Most of the time. The "library" workflow works for applications too. Put your direct dependencies in setup.py. Build wheels of everything and upload them to an internal PyPI server. Pin everything in requirements.txt.
IvanAnishchuk 8y ago
> We could have built a tool to manipulate `requirements.txt` files There's pip-compile from https://pypi.org/project/pip-tools/ https://pypi.org/project/pip-tools/ that does exactly that. Pipenv uses its resolving mechanism if I'm not mistaken. It produces standard req.txt file with versions pinned and supports separate dev requirements. It had some bug with upgrades last time I checked though, not sure whether it's resolved, currently considering using it for projects at work.
- SmirkingRevenge 8y ago
  Have used pip-tools for a long time... its very uncomplicated and just makes things pretty darn simple. Since its all just requirements files with pip-tools, its been fairly commitment free, in that I haven't had to substantially rework any major bits of workflow to use it - nor would I to remove it. Not sure I could say the same thing about pipenv and/or poetry.

by rtpg 8y ago

pseudalopex 8y ago

An internal application can exist in one specific universe. Most of the time. The "library" workflow works for applications too. Put your direct dependencies in setup.py. Build wheels of everything and upload them to an internal PyPI server. Pin everything in requirements.txt.

IvanAnishchuk 8y ago

> We could have built a tool to manipulate `requirements.txt` files There's pip-compile from https://pypi.org/project/pip-tools/ https://pypi.org/project/pip-tools/ that does exactly that. Pipenv uses its resolving mechanism if I'm not mistaken. It produces standard req.txt file with versions pinned and supports separate dev requirements. It had some bug with upgrades last time I checked though, not sure whether it's resolved, currently considering using it for projects at work.

SmirkingRevenge 8y ago
Have used pip-tools for a long time... its very uncomplicated and just makes things pretty darn simple. Since its all just requirements files with pip-tools, its been fairly commitment free, in that I haven't had to substantially rework any major bits of workflow to use it - nor would I to remove it. Not sure I could say the same thing about pipenv and/or poetry.