Warehouse: functionality to rename a project

[ewdurbin]

At this point, there are some admin tools in pypa/pypi-legacy i'm not comfortable using to rename projects when users request such an operation. Some examples are modifications of case or underscore/hyphen swaps which are equivalent after applying safe_name (myPackage => mypackage, or my-package -> my_package)

We should establish a process and enforce it via whatever mechanism we use to perform such an operation (code, admin ui, carrier pigeon).

[dstufft]

Renaming doesn't really work in general because even if you rename the file, the contents of said file are going to still be using the old name. The only renames that really work at all are if they normalize to the same thing.

[dstufft]

Well, I guess we could allow you to rename as long as the normalization still matched, would that satisfy this issue?

[brainwane]

In our meeting today we double-checked and agreed that this new admin feature can wait till after Warehouse launch.

[jacebrowning]

(I was brought here by https://twitter.com/brainwane/status/976489373607772161)

Here's my use case:

https://pypi.python.org/pypi/coverage-space was originally named coverage.space, but I realized this was problematic because that name requires quoting to include in a Pipfile. I thought I could upload newer versions of the PyPI package as coverage-space, but I was getting an error message along the lines of "name must start with coverage.space". I couldn't find a way to rename the PyPI package so I ended up deleting all versions and uploading 1.0 as coverage-space.

[brainwane]

Thanks @jacebrowning and I'm sorry for the trouble! We'll take this into account as we work on Warehouse and improve documentation and user support processes.

coverage.space/coverage-space looks like a cool project! (Here it is in the new PyPI.)

[jacebrowning]

Is there any way I can set up a redirect to avoid broken downloads?

It would be awesome if pip install coverage.space==1.2.3 redirected to coverage-space==1.2.3.

[ewdurbin]

the two project names share the same normalized name, so a rename would have been more tenable before project deletion. unfortunately we don’t have tooling for a rename, so that would have had to have been built.

as far as what we do now, restoring deleted projects may be doable but is not a task we’ve undertaken before.

filenames cannot be reused, and I believe that will remain the strict rule, so the only real recourse to a project deletion is to upload replacement post0 or similar releases with the new name.

[jacebrowning]

Thanks @ewdurbin. Based on a rough search, I don't see more than 1000 projects depending on the package I "renamed" and probably less than a few percent are actively maintained. I think I can manage to support those few affected.

It might be nice if going forward "normalized" names are treated as equivalent. That is to say:

• An admin of "foo-bar" could upload "foo.bar" to the same package
• A non-admin of "foo-bar" could never upload "foo.bar"

[ewdurbin]

this issue is intended to track support tooling for the purpose of renaming existing projects. indeed it's something that should be supported as long as the new project name normalizes. part of that must _absolutely_ be enforcing ACLs against project names for maintainers, that would make renaming a project a user concern and not an admin concern, which is a big win.

basic "workflow" would be to either support that by allowing a user to initiate the rename via the UI or by uploading a new release with the new name (which _must_ normalize to either a non existent project name or a project name that they have ownership of).

the unfortunate side effect would be two fold:

• clear error messages around what's gone wrong (user tries to create a new project named... New.Project but are told that new-project is already taken)
• possible accidental renaming (maintainer uploads a project that conflicts with one they forget they own leading to all kinds of ?!)

ultimately there remains some level of concern for the client implementations using PyPI here as well. pip already handles implicit normalization when requesting Project.Name vs project-name while pipenv has more exacting requirements.

i ultimately support the freedom for maintainers to choose their project's name as displayed, but also fail to see the full value in such a potentially disruptive operation (even if a deletion had not occurred) to avoid some quotes.

[di]

Blocked on https://github.com/pypa/warehouse/issues/4772.

[di]

No longer blocked.

[brainwane]

@di do you have any policy/architecture concerns about this, or is it open for someone to implement? Is this something we should seek volunteer help to work on?

Since this potentially blocks #1506 I figure it's something worth pushing on.

[dstufft]

I think this works now? If you upload a project and change the name, as long as it normalizes to the same name as before, the project will be renamed on PyPI. We don't support arbitrary renaming where you can rename foo to bar, but I don't think we ever really could?

[di]

Yeah, since #4783 we have the ability to rename a project when a new release is made.

This issue is a bit old, I think it might intend to allow admins or owners to rename a project _without_ making a new release, but I'm not really sure that's necessary.

[brainwane]

@ewdurbin and @jacebrowning could you reply and let us know whether your use cases are now taken care of?

[ewdurbin]

looks like the "different name same normalization" use-case is covered by #4783 to me!

[jacebrowning]

Yes, I believe my use cases are now taken care of.

[brainwane]

OK, great, glad that's cleared up and sorry for misunderstanding!