On 29 Sep 2014 18:49, "M.-A. Lemburg" <m...@egenix.com> wrote: > > You are missing out on cases, where the release process causes files to > be omitted, human errors where packagers forget to apply changes to > e.g. documentation files, version files, change logs, etc., where > packagers want to add information that doesn't affect the software > itself, but meta information included in the distribution files. > > Such changes often do not affect the software itself, and so are not > detected by software tests.
Fixing such packaging errors is the primary intended use case of the "post" field in PEP 440. Alternatively, many projects will just spin a new release that addresses those issues, just as they would for any other bug. Both of those approaches have the advantage of letting users (especially those operating mirrors, or downloading tarballs and feeding them into a separate redistribution system) easily tell whether or not they have the fixed version. > If I understand you correctly, you are essentially suggesting that it > becomes impossible to ever delete anything uploaded to PyPI, i.e. > turning PyPI into a WORM. No, deletion remains supported. The only capability being removed is silent substitution of hosted files with different ones bearing the same name. So if, for example, release "3.1.4" had a packaging error, then deleting it would still be possible, but the replacement would need to be something like "3.1.4.post1" or "3.1.5", rather than being permitted to reuse the "3.1.4" name. > This would mean that package authors could never correct mistakes, > remove broken packages distribution files, ones which they may be > forced to remove for legal reasons, ones which they find are infected > with a virus or trojan, ones which they uploaded for fun or > by mistake. Removal will still be supported, for these kinds of reasons. Only the silent file substitution loophole is being eliminated - packaging fixes are still fully supported, they're just going to be required to be done in a way that is visible to end users. > This doesn't have anything to do with making the user experience > a better one. It is ignorant to assume that package authors who > sometimes delete distribution files, or at least want to have the > possibility to do so, don't care for their users. We are in > Python land, so most authors will know what they are doing and > do care for their users. Again, only the silent file substitution loophole is being removed. Outright deletion remains a fully supported feature. > After all: Why do you think I'm arguing against this proposal ? > Because I want users of our packages to get the best experience > they can get, by downloading complete, correct and working > distribution files. You are entirely correct that removing the ability to delete hosted files would be a bad idea (even though we can't guarantee deletion from third party mirrors). However, there is nothing user friendly about retaining the ability for software publishers to silently replace the contents of a PyPI hosted file without bumping the version number. In particular, that practice actively risks breaking deployments for anyone using the peep installer to automatically cache the first seen hash for each released file (since peep can't tell the difference between the package author doing it and a malicious attacker doing it). > This whole idea also has another angle, namely a legal one: > the PSF doesn't own the distribution files it hosts on PyPI. > > So far, the argument to not fix the much too broad license on PyPI > was that authors were able to delete files on PyPI to work around > the unneeded "irrevocable" part of that license. > > With the suggested change, authors would have to give up complete > control over their distribution files to the PSF in order for their > packages to be installable by pip using its default settings. We are not removing the ability to delete files. > This kind of lock-in and removal of author rights is not something > I can support as PSF director. Those authors are the ones that have > created a large part of our Python eco system and they are the ones that > have put in work to get Python to where it is now: one of the best > integrated programming languages you can find. We owe a lot to those > authors and need to care for them. Yes, we do, but requiring them to bump their version numbers when changing the contents of published files seems like an entirely reasonable constraint to me. If the proposal was to remove the ability to delete files entirely, I would be on your side. Fortunately, that is not the proposal - the proposal is solely to prevent silently modifying their contents without renaming them. > Finally, changes such as the above will result in more authors > to switch to alternative hosting platforms such as conda/binstar.org > or plain github clone + setup.py install (which is becoming increasingly > popular). Do you really believe that this will make the user experience > a better one in the long run ? Other release hosting services do not, as far as I am aware, typically allow silently replacing a previously published file with a new file containing different contents. Hash based version control systems in particular prevent it by design. Linux distributions *certainly* disallow reusing the same "epoch, name, version, release" details for different software releases - if a release contains a packaging error, addressing that is one of the things bumping the distro supplied "release" field covers. > If we want to make it attractive for package authors to host their > packages on PyPI, we have to give them flexibility, respect their > rights and be welcoming. And we do. We just impose some contraints (like "deleting files is OK, silently replacing them with something else is not") on behalf of end users. The external hosting support is then the mechanism by which authors can retain complete and total control over their release process. That approach avoids all licensing concerns (including those related to US export controls), as well as ensuring they have the ability to silently change the contents of previously released files if they choose to do so (although, as noted above, actually doing so may break installation for anyone installing with peep, which checks file hashes based on the first version downloaded). Regards, Nick. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Sep 29 2014) > >>> Python Projects, Consulting and Support ... http://www.egenix.com/ > >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > 2014-09-30: Python Meeting Duesseldorf ... tomorrow > > ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
