Name of dependency does not get updated in Project.toml if it changes name

KristofferC commented 5 years ago

To repro, add e.g Crayons:

(TestRename) pkg> add Crayons
  Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
 Resolving package versions...
  Updating `~/TestRename/Project.toml`
  [a8cc5b0e] + Crayons v4.0.0
  Updating `~/TestRename/Manifest.toml`
  [a8cc5b0e] + Crayons v4.0.0
  [2a0f44e3] + Base64 
  [8ba89e20] + Distributed 
  [b77e0a4c] + InteractiveUtils 
  [56ddb016] + Logging 
  [d6f4376e] + Markdown 
  [9a3f8284] + Random 
  [9e88b42a] + Serialization 
  [6462fe0b] + Sockets 
  [8dfed614] + Test

Now, change the name field of Crayons in the registry and do up:

(TestRename) pkg> up
 Resolving package versions...
 Installed Crayons_foo ─ v4.0.0
  Updating `~/TestRename/Project.toml`
  [a8cc5b0e] - Crayons v4.0.0
  [a8cc5b0e] + Crayons_foo v4.0.0
  Updating `~/TestRename/Manifest.toml`
  [a8cc5b0e] - Crayons v4.0.0
  [a8cc5b0e] + Crayons_foo v4.0.0

(TestRename) pkg> st
    Status `~/TestRename/Project.toml`
→ [a8cc5b0e] Crayons_foo v4.0.0
┌ Warning: Some packages (indicated with a red arrow) are not downloaded, use `instantiate` to instantiate the current environment
└ @ Pkg.Display /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Display.jl:220

shell> cat Project.toml
[deps]
Crayons = "a8cc5b0e-0ffa-5ad4-8c14-923d3ee1735f"

The dep in Project.toml is still called Crayons and the package can not be loaded with either the new or the old name.

StefanKarpinski commented 5 years ago

When you've done an up this should definitely change to use the new name of the package.

StefanKarpinski commented 5 years ago

I’m actually not 100% sure this is a bug. I think the name to load a package by needs to be derived from the name in the package at the version that is resolved. If the package and repo gets renamed but your manifest still uses an order version from before the rename, then we should use the old name.

KristofferC commented 5 years ago

The package at the resolved state does have the new name. And in fact, the Manifest updates to the new name (as is seen by the status output). It's just the project file that doesn't get updated (presumably because some left over uuid to name cache).

StefanKarpinski commented 5 years ago

Ok, so the thing to potentially change here is:

When a package in the project file is upgraded to a version where it has a different name than the one that is present in the project file (as determined by the name entry in the package's project file at that version), the name in the project file should be automatically changed to reflect the project's new name.

I have a few questions/issues:

Are we really comfortable with automatically modifying the project file when upgrading/downgrading packages? Normally that only affects the manifest file. This would be the first situation where upgrade/downgrade operations can change a project file in any way.
The end user still needs to change their code to reflect the new package name. They won't be able to keep using the old name, so just upgrading/downgrading is not really sufficient. You need to also: (1) modify the project file and (2) modify the usage of the renamed package. At least in the case of named environments there is no project code so this second step doesn't matter.
Does doing one but not the other make sense? Should we instead consider that a name mismatch with a new version of a package indicates an implicit incompatibility? So the user would have to explicitly ] rm $old_name and ] add $new_name or maybe we could prompt the user when a rename happens and ask them if they also want help fixing their code?
Should we instead try to make it possible to support using a package by both its own and new name? Then there can be a smoother transition period, but at some point, one presumably still wants to drop support for the old name and force people to change the name they use a package by, at which point we face the exact same situation, so it's unclear if this is really worth it.

KristofferC commented 5 years ago

This would be the first situation where upgrade/downgrade operations can change a project file in any way.

Good point, perhaps that is why the name in the Project file doesn't update.

The end user still needs to change their code to reflect the new package name.

That is true but also true for any potential breaking change so I don't see this as very different.

Should we instead try to make it possible to support using a package by both its own and new name?

This is one reason when checking the installed version of a package makes sense. To support the old name you could do:

if version_of_pkg_with_uuid("$uuid_for_pkg_with_changed_name") < VERSION_WHERE_NAME_CHANGED
    using OldName
    const NewName = OldName
else
    using NewName
end

I don't think there is much worth in trying to allow older packages to use the new package with the new name and still have that work. Changing the name is effectively a breaking change then.

StefanKarpinski commented 5 years ago

I guess one argument for changing the name in the project file is that then when someone tries to test the code, they get a fairly clear error about "Unknown package OldName", as opposed to the probably more confusing error they'll get if the name in the project file and the manifest file don't match. Although, arguably, we could also detect the name mismatch and at that point print an error message with the search and replace that someone needs to do to fix it everywhere.

JuliaLang / Pkg.jl

Name of dependency does not get updated in Project.toml if it changes name #1231