3 ms·
Or, more importantly (in my case), very easily bundle pure Python code with your application. I understand the arguments against it, but in any project that mig
by davb 13y ago
Or, more importantly (in my case), very easily bundle pure Python code with your application. I understand the arguments against it, but in any project that might produce deliverables that will be in play for more than a few weeks the first thing I do is create a "lib" folder where any third party dependencies live and get imported from.
With Python this is usually very easy.
I've maintained my fair share of legacy code and more often than not one of the biggest issues is tracking down ancient libraries which work with my code. There are very few packages I trust to maintain fairly stable interfaces and be available years into the future (things like Apache HTTPd, PostgreSQL and memcached); everything else lives in the project lib folder. I can "hg clone" my app at any time and get the exact version of the third party packages I need.
Every so often I update the packages and test the integration.
- lotyrin 13y agoThis is why good dependency management systems support both specifying compatible semver ranges but also pinning/locking specific releases. You get nice one-step install/update/add/remove for your deps with the tool, but a fresh checkout can get the last known working versions and deploys can be guaranteed to use the same versions as were run in CI, etc. Looking now, it seems that pip can finally do this with pip-compile.