Move rez.vendor.version
outside of rez.vendor
#1484
Closed
JeanChristopheMorinPerso
started this conversation in
Proposals
Replies: 3 comments
-
I'm trying something new. I created a discussion instead of an issue to see if the use of threads will make it easier to discuss. We can also convert to an issue if needed. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I created a PR that implements this proposal: #1534 |
Beta Was this translation helpful? Give feedback.
0 replies
-
This was released on 2.114.0. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Rez's version and requirement classes live in a
rez.vendor.version
subpackage. This will become a problem as we grow and extract some things into their own plugins outside of the main repository.These modules anyway were written by Allan entirely and were put into vendor because the goal was to eventually extract them and make them available on PyPI. But it turns out there is already enough version libraries on PyPI and ours are quite specific to rez.
I propose to move them outside of the vendor folder and make them first class citizens.
Current layout
rez.vendor.version.version
Public classes:
Public functions:
Private classes (starting with
_
) will eventually need to be made public when we start to add type hints into our code base.rez.vendor.version.requirement
Public classes:
rez.vendor.version.util
Public classes:
Public functions:
Proposed layout
rez.vendor.version
->rez.version
rez.vendor.version.version
->rez.version._version
rez.vendor.version.requirement
->rez.version._requirement
rez.vendor.version.util
->rez.versino._util
rez.version
(__init__.py
). This will shorten the import path and will also explicitly state what is public and what isn't.How to introduce this change
Rez doesn't have a defined public API. This raises questions on how we could do this change. Similar changes were previously done, so we have a precedent to look at.
rez.package_maker__
,rez.package_resources_
andrez.packages_
were moved torez.package_maker
,rez.package_resources
andrez.packages
respectively.On top of that, the original names were kept, but importing them will trigger deprecation warnings.
We could do something similar for the version modules. But we are not particularly good at deprecating things. And I also think that it would be quite fair if we simply removed the modules entirely from where they are right now since they lived in a
vendor
folder. If a user of rez imports these, they were kind of warned by thevendor
name.It could be a good occasion to bump the version fo rez from 2 to 3 and remove the deprecated stuff and also bump the minimum required python to 3.7 for prod installs (not API).
Beta Was this translation helpful? Give feedback.
All reactions