4 ms·

Age is a good indication if there were serious issues with this approach we would have found them. There seem to be a lot of strange fears from python develope

Age is a good indication if there were serious issues with this approach we would have found them. There seem to be a lot of strange fears from python developers about this approach and my comment on age was an attempt to assuage those fears. Since ruby developers are quite happy with bundler (at least in comparison to other communities) and have been for some time it's a reasonable point and not the only one I made. I'm not sure how pip plans to use the lock file for projects distributed via pip. They may very well have a solution planned for that. However, for projects that are distributed by source (which are many) the lock file ensures deterministic builds, and requirements.txt generally doesn't without being pedantic with your versions.

scarygliders 10y ago
> There seem to be a lot of strange fears from python developers There you go again. This isn't fear. It's asking the question of: What. Is. The Damn. Point. Of. This? I have yet to see a simple, cogent explanation of why this is better than a list of requirements specifying; pyside==x.y.z pillow==x.y.z As opposed to this proposed Thing. You know what this reminds of? It reminds me of replacing super simple .INI text files with configuration files stored as XML - change for the sake of it, because Change! Now, I'd love to see a very simple explanation and justification on why we should all move to this new Thing you're making. Something like "This new Thing is better because..." , followed by practical /examples/ , because right now, all I see is More Complicated Stuff For The Sake Of It.
- examancer 10y ago
  There were clear fears/risks/concerns stated by witten directly above. I didn't invent the idea of fears being stated out of whole cloth. > subject to all the abuse you can introduce > might cause [...] problems I've said a few things about the potential benefits, though I am not involved in the project. The actual authors offer the best list of benefits: https://github.com/pypa/pipfile#the-concept https://github.com/pypa/pipfile#the-concept They also point out this will eventually be built into pip, so it will have the benefits of all the existing workarounds like pip-tools without any setup. It does seem like a lot more than change for the sake of change, and along with it since there is so much change why not take the opportunity to adopt a flexible DSL built for future extension so there is less real change in the future.

scarygliders 10y ago

> There seem to be a lot of strange fears from python developers There you go again. This isn't fear. It's asking the question of: What. Is. The Damn. Point. Of. This? I have yet to see a simple, cogent explanation of why this is better than a list of requirements specifying; pyside==x.y.z pillow==x.y.z As opposed to this proposed Thing. You know what this reminds of? It reminds me of replacing super simple .INI text files with configuration files stored as XML - change for the sake of it, because Change! Now, I'd love to see a very simple explanation and justification on why we should all move to this new Thing you're making. Something like "This new Thing is better because..." , followed by practical /examples/ , because right now, all I see is More Complicated Stuff For The Sake Of It.

examancer 10y ago
There were clear fears/risks/concerns stated by witten directly above. I didn't invent the idea of fears being stated out of whole cloth. > subject to all the abuse you can introduce > might cause [...] problems I've said a few things about the potential benefits, though I am not involved in the project. The actual authors offer the best list of benefits: https://github.com/pypa/pipfile#the-concept https://github.com/pypa/pipfile#the-concept They also point out this will eventually be built into pip, so it will have the benefits of all the existing workarounds like pip-tools without any setup. It does seem like a lot more than change for the sake of change, and along with it since there is so much change why not take the opportunity to adopt a flexible DSL built for future extension so there is less real change in the future.