I typically start a virtualenv (optional) and run python setup.py develop but I can't see a downside to adding this.

retest this please

The recommended way is to use virtualenv, I wouldn't trust anything else (other than actual system packaging) to try and run ceph-volume - or any other Python project.

In both the unit and functional tests, virtual environments (virtualenv) is used throughout, and I don't see why the orchestrator tests couldn't do something similar. Running python setup.py develop inside a virtualenv would immediately guarantee the availability of the executable

The recommended way is to use virtualenv, I wouldn't trust anything else (other than actual system packaging) to try and run ceph-volume - or any other Python project.

vstart.sh doesn't really support running mgr modules in a dedicated virtualenv: If you want to run mgr modules, you need to have the packages installed in your system. My use case is to execute c-v from within a mgr module. In order to do that, I'd like to have a simple way to invoke c-v.

Also, running python -m ceph_volume makes use of system packaging.

Please, also have a look at https://chriswarrick.com/blog/2014/09/15/python-apps-the-right-way-entry_points-and-scripts/ or https://github.com/jgehrcke/python-cmdline-bootstrap regarding the use of __main__.py as the preferred entrypoint.

In both the unit and functional tests, virtual environments (virtualenv) is used throughout, and I don't see why the orchestrator tests couldn't do something similar.

See above.

Running python setup.py develop inside a virtualenv would immediately guarantee the availability of the executable

If 'make` is not creating a virtualenv, I don't know, how I could create an environment reliably.

It is tremendously unfortunate that we need to start supporting new ways of invoking ceph-volume because vstart.sh doesn't support virtualenv.

The linked site describes using entry_points (we are doing this recently in ceph-volume) as well as being able to do python -m my_project.

ceph-volume is not a single script (or small project) without dependencies. These dependencies aren't declared in setup.py today, but if we were to add dependencies the python -m ceph_volume would not work correctly. One would need to install these dependencies somehow. My guess is that vstart.sh doesn't support that either. Even if manually added, those would need to be cleaned up after testing (otherwise pollution of the environment would occur), but removing dependencies that are available globally to the system (that is, not in a contained virtualenv) are problematic to remove correctly.

There is no need for other tools like vstart.sh to support running mgr modules in a virtualenv. One can install a virtualenv outside of everything, and invoke the executable in <venv>/bin/ceph-volume

I am -1 on allowing this changeset, would prefer to see tests isolate ceph-volume in a virtualenv, either manually or via vstart.sh, or simply rely on a packaged development version of ceph that handles all of this already

It is tremendously unfortunate that we need to start supporting new ways of invoking ceph-volume because vstart.sh doesn't support virtualenv.

probably we could install ceph-volume to a venv and use the installed ceph-volume ?

edit, i was just repeating Alfredo's comment...

It is tremendously unfortunate that we need to start supporting new ways of invoking ceph-volume because vstart.sh doesn't support virtualenv.

probably we could install ceph-volume to a venv and use the installed ceph-volume ?

Yes, exactly what I think should happen

It is tremendously unfortunate that we need to start supporting new ways of invoking ceph-volume because vstart.sh doesn't support virtualenv.

probably we could install ceph-volume to a venv and use the installed ceph-volume ?

Yes, exactly what I think should happen

I dislike the idea of creating and installing the venv from within the mgr module, as it would mix runtime and compiletime. Thus, this will end up as being a cmake script in src/c-v that creates a venv similar to the cmake integration of some other mgr modules. Like run-tox + CMakeLists.txt

I'm still preferring this solution, but for now, this is replaced by #25236