3 ms·
Yes, you're absolutely right about requirements.txt. However as you say, it's a problem when you have to start considering transitive dependencies. In fact, f
by rleigh 8y ago
Yes, you're absolutely right about requirements.txt. However as you say, it's a problem when you have to start considering transitive dependencies. In fact, for the case I mentioned, this became a problem because there were so many it became increasingly complex; you ended up having to start moving more and more of the transitive dependencies directly into the requirements file. And this isn't very scalable.
That on its own would be somewhat manageable. But if you start getting requirements to update "just one more module" for some specific functionality, you eventually end up at the point where it's not possible to provision a functional set of modules. That's where I ended up with 2.6, and 2.7 is likely to be just the same, in my opinion.
- vetinari 8y agoTransitive dependencies (or what I called inherited from other packages) can be solved with pip freeze in existing working environment; it will list them too. New development, on the other hand, will be difficult. As it usually is, when you develop in something that has been obsoleted years ago. If you are still developing the system, instead of just keeping it running, shouldn't you spend some resources on python3 migration, too? The modules you need are already there.
- rleigh 8y agoNo disagreement here from me! The times we have had to update things have been when the existing modules broke. One example which comes to mind from the recent past is when urllib TLS certificate stuff broke and it needed updating. In that case, it didn't cause collateral damage, but we were forced to do it to keep things working. Externally-enforced changes like this could potentially cause breakage in the future if they drop python 2.7 support directly or indirectly.