Forwarding as I mistakingly sent this directly to Matin, sorry!
Forwarded message: > From: Donald Stufft <[email protected]> > To: "Martin v. Löwis" <[email protected]> > Date: Monday, January 30, 2012 3:36:09 AM > Subject: Re: [Catalog-sig] Proposal: close the PyPI file-replacement loophole > > A Major goal in any deployment/installation system is reproducible builds. > Allowing re uploads directly goes against this goal. I (and a lot of Python > developers I would imagine) purposely pin to specific versions because we > *know* those versions work. Currently if I rely on PyPI or any of it's > mirrors I just have to cross my fingers and hope that the file i'm getting is > the file that I tested against. > > A responsible author wouldn't change his files after people are using it. > Unfortunately not all authors are responsible which is why restrictions > should be put in place. > > I think there are very clear bad things that could happen due to mutable > packages, I can't think of a single bad thing that could happen due to > immutable packages other than "if the author messed something up he might > have to increase his version number". Increasing a version number is a very > minor problem compared to breaking software. > > So my questions to you are: > > 1. What is the worst case if packages are made immutable? > 2. What is the worst case if they are kept mutable? > 3. Best case for immutable? > 4. Best case for mutable? > > That I can think of it's: 1) Author Might have to "waste" a version number > uploading a fix 2) Author might break (or introduce major security > vulnerabilities), inadvertently or otherwise exiting software 3) People > depending on packages can use PyPI and be secure in the fact that what they > got today will be the same as what they get tomorrow 4) People depending on > packages can get "secret" bug fixes. > > Between the two the worst case for immutable is basically a noop, and the > worst case for mutable is a very serious problem which leads many people to > needlessly abandon PyPI for when installing packages matter and use their own > internal systems. I very strongly feel that the worst case for mutable is a > serious problem and it outweighs the very minor benefit package authors get > from being able to re upload. > > On an additional note, a good compromise might be to allow reuploads for the > first 30 minutes or an hour, and after that prevent it. You still provide > that minor benefit in the only situation it's a valid use in my opinion (the > "oh no I just uploaded a package and it was broken"), but you let people be > secure in the fact that when I test my software against a specific version, I > can install that version over and over again and get the same results. > > On Monday, January 30, 2012 at 3:04 AM, "Martin v. Löwis" wrote: > > > > -1. There are plenty of ways to check whether the file was modified if > > > > you already have a copy of it. Users just need to accept that files may > > > > change, and package authors need to accept that users may retain old > > > > copies of a file even after they replaced it. > > > > > > > > > > I don't always have a copy of the file, I might only have a reference > > > such as slumber==0.3.0. > > > > > > > > > The better. A responsible author, when replacing an existing file, > > should make sure that it is reasonably compatible with the previous > > copy of the file. E.g. the update may include corrected typos or include > > files that the previous copy didn't include; the previous copy may have > > actually not worked at all in some circumstances. > > > > Now, it may be that the author does break your code by mistake when > > replacing a file. You should then report that to the author, asking > > him to restore the original file and be more careful in the future. > > > > Regards, > > Martin > > > > > > > >
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
