[Distutils] PyPi not allowing duplicate filenames

[Chris Barker]

On Wed, Oct 14, 2015 at 9:56 AM, Dave Forgac <tylerdave at tylerdave.com>
wrote:

> This was discussed recently here:
> https://github.com/pypa/packaging-problems/issues/74
>

and on this list at other times. Though the above issue was pretty focused
on restoring a deleted file without any changes -- which seems like a
no-brainer to me, as long as someone wants to put the effort into the
infrastructure.

(the soft delete option seems like a good idea to me).

But I'm talking about the cases of "whoops! I really wish I hadn't uploaded
that one". We can improve the tooling (some discussion on this in this
thread right now...), but people are people and some of us are stupid
and/or careless. So this WILL happen.

And it just seems pedantic to say: hey -- you've already put that one there
-- maybe even two minutes ago, so there is NO WAY to fix your mistake. If
it happens quickly, then no one has downloaded it, it hasn't made its way
to the mirrors, etc...

And again -- we are all adults here: if you as the package maintainer want
to do somethign that is sonfusing to your users, is it up to PyPi to never
let you do that? (I think it IS up to PyPi to strongly recommend that you
don't -- i.e. make it hard to do, and impossible to do thoughtlessly)

On Wed, Oct 14, 2015 at 10:00 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:

> > You should have to jump through all sorts of hoops, and make it
> > really clear that it is a BAD IDEA in the general case, but it'd
> > be good to have it be possible.
> [...]
>
> It used to be possible.


Was it also easy to do without very careful consideration? Or were the
hoops I mentioned in place?

I can't find it right now, but I think someone in this thread suggested a
"staging area", so we could essentially do a trail run: upload to PyPi,
tell a few trusted friends about it, have them test it, then, and only
then, push it to the official channel. Maybe the infrastructure for that
would be more work than it's worth, but I like it.

This would fit into the basic principle that you should always be able to
test something in as close the final environment as possible, before you
commit to it.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151014/a67647e9/attachment.html>