Define the Python version used by PipEnv using UV to create the venv #19388
Conversation
| pip_env = PipEnv(self, py_version="3.11.6") | ||
| pip_env.install(["{pip_package_folder}"]) | ||
| pip_env.generate() | ||
| self.run(pip_env._get_env_python(pip_env._env_dir) + " --version") |
There was a problem hiding this comment.
This ugly access, need some nicer public API
There was a problem hiding this comment.
This is only for testing purposes to verify that we are using the defined python version, but it has no real use in any recipe
There was a problem hiding this comment.
This is related to the other ticket, if we want to give more visibility over the tools (uv or the Python version)
Once uv is there, and it is possible to install different python versions inside the PipEnv i'd say it is super likely that users might want to run python -m ... or python -c ..., with that specific Python that they explicitly requested.
So this self.run("python --version") is evidencing a very likely need of making that public API?
There was a problem hiding this comment.
Ah! In that case we can expose it without any problems, of course
conan/tools/system/pip_manager.py
Outdated
| "Scripts" if platform.system() == "Windows" else "bin") | ||
| # init the venv | ||
| if py_version: | ||
| self._crete_uv_venv(py_version) |
There was a problem hiding this comment.
What other advantages of using uv could PipEnv enjoy?
Do we want a generic access interface to it like def install(self, packages, pip_args=None):?
There was a problem hiding this comment.
The install interface is the same, It only affects how the virtual environment is created
| :param py_version: Optional python version for the virtualenv using UV | ||
| """ | ||
| super().__init__(conanfile, folder, name) | ||
| self._base_env_dir = os.path.abspath(os.path.join(folder or conanfile.build_folder)) |
There was a problem hiding this comment.
| self._base_env_dir = os.path.abspath(os.path.join(folder or conanfile.build_folder)) | |
| self._base_env_dir = os.path.abspath(folder or conanfile.build_folder) |
| :param conanfile: The current conanfile "self" | ||
| :param folder: Optional folder, by default the "build_folder" | ||
| :param name: Optional name for the virtualenv, by default "conan_uvenv" | ||
| :param py_version: Optional python version for the virtualenv using UV |
There was a problem hiding this comment.
Here says it's optional but it's not
| f"environment using '{self._default_python}': {e}") | ||
|
|
||
|
|
||
| class UVEnv(PythonVirtualEnv): |
There was a problem hiding this comment.
Have you considered not exposing a new UVEnv class? Because in the end uv is just the method we use for creating the environment but the functionality is the same for both exposed public classes. Maybe it should be a single class that you instance like this?
pip = PipEnv(self, backend="uv", ...)
If we keep the two different public classes (which I think is fine) maybe you should consider composition instead of inheritance for the common functionality.
There was a problem hiding this comment.
Could make sense, maybe that would also be a rename of the class to PyEnv?
We could do an alias first, deprecate the PipEnv with a warning to not break existing usage.
3 participants
Changelog: (Feature | Fix | Bugfix): Describe here your pull request
Docs: https://github.com/conan-io/docs/pull/XXXX
developbranch, documenting this one.