Add package name remapping functionality

[JeanChristopheMorinPerso]

In relation to #55, it would be handy to have a way to control the names of the packages that we create. This would probably be a mapping/dict either defined through a CLI, or a config setting.

We might also need a way to automatically prefix all package names?

[MrLixm]

Hello, great idea.
That would also be interesting to provide suffix/prefix for versioning.
For example we are suffixing all "vendors" package with an additional version token to create proper immutable release (meaning you will never have to overwrite an existing release).
Currently it is cumbersome to have such a workflow with rez-pip2 and it's just simpler to overwrite an existing release when needing to rerelease for any reason.
Maybe worth opening a new issue for it ?

[JeanChristopheMorinPerso]

Hi @MrLixm !

For example we are suffixing all "vendors" package with an additional version token to create proper immutable release (meaning you will never have to overwrite an existing release).

Can you clarify what you mean by this? I'm not too sure to understand the use case or the problem you are solving with add a suffix to versions.

[MrLixm]

Ha sorry, in the case you need to re-release a version that has already been released.
For example you release a package pytest-7.4.3 with rez-pip but then you find out that you actually need to patch that version for whatever reason. You will have to override the existing version on disk when trying to re-release which if I understand is something that should be avoided as it can cause issue with caching and is just against the logic of having immutable versions ?
The solution we use is to add a suffix where we would first deploy pytest-7.4.3.1, then pytest-7.4.3.2.

[JeanChristopheMorinPerso]

I would prefer if users change the version in the forked package itself. The python ecosystem even has a system to handle this kind of scenario called local version identifiers. rez-pip (the original) and rez-pip2 (this repo) both already know how to handle this.

[JeanChristopheMorinPerso]

Alright, I have a little bit more time to expand on my last reply.

In the workflow you explained, you take an open source project, fork it and do some changes. If you are doing modifications, then you probably want to track these changes in some ways. So while being there, you can also add a little +1 to the project's version before building the wheel. If you don't do that, you run into the possibility of accidentally overriding changes, and you'll also have to remember the last patch version you did or search for it to know what next version to use. Like, we wouldn't have a way to automatically bump the local version identifier.

There is another aspect to take into consideration too. This new rez-pip doesn't have the ability to build wheels. It can only install wheels. So unless you manually download wheels, unpack them and modify them to then re-pack them, or fork projects and manually build wheels from source.

So all in all, I don't think it's a good idea to add a version suffix functionality. At least not with the use case you provided. Please let me know if I misinterpreted what you said.

[MrLixm]

It does make sense, I'm still trying to figure out the workflow you mentioned when needing to patch a software. With that I don't have any more argument in favor of opening the versioning right now. I let you know if I find any during my investigation 😛