Strongly encourage to update python ?

[asmodehn]

Is it suitable for catkin_pip to strongly encourage users to update their python system ?

Ex : everytime you use not latest bower

   ╭─────────────────────────────────────╮
   │                                     │
   │   Update available 1.7.7 → 1.7.9    │
   │   Run npm i -g bower to update      │
   │                                     │
   ╰─────────────────────────────────────╯

Catkin-pip enable the use of latest python as in a python workflow.

Maybe we should target latest (supported) python version, to not have to deal with all backward compatibility issues ? And instead of hiding latest pip and setup tools in a separate folder, strongly encourage users to upgrade their system on (via pip) ?

It seems to me that is what a python user would do...

[asmodehn]

It might come in the way of normal catkin behaviour, relying on the system packages.

But it would make using latest python tools (pip, setuptools, testrunners, mocks, compatibility libs, etc. ) much easier.

=> we probably need a solution to enable both behaviour.
We will always upgrade low level python packages. But user can specify to do this like when installing a pip package :

• globally on system (/usr/local/lib)
• user (PYTHON userspace)
• workspace (current behaviour that require sourcing workspace before using it)

[asmodehn]

In my view this will also make many operations much easier to follow, and will drive people to use latest. For testing, documentation, etc.

It seems better to wait for 0.2.0 to avoid having to manage too many different workflows (devel, install python or not, etc.). see #18.

[asmodehn]

I found out pip also does this now :

(pyzmp)alexv@AlexV-Linux:~/Projects/pyzmp$ pip install .
You are using pip version 7.1.0, however version 8.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

[asmodehn]

Note debian default to install with --user nowadays : pypa/pip#3826

  --user                      Install to the Python user install directory for your platform. Typically ~/.local/, or %APPDATA%\Python on Windows. (See the Python documentation for site.USER_BASE for full details.)  On Debian systems, this is the default when running
                              outside of a virtual environment and not as root.
  --system                    Install using the system scheme (overrides --user on Debian systems)

[asmodehn]

Pip from debian defaults to user space. As a result we need to pass 'system' option, to be able to specify a prefix...

But when the pip command scripts uses a pip package from python/venv ( not debian one ) the 'system' option is not supported.

Catkin pip cannot easily know if a user uses a debian pip or an original pip.

Yet catkin pip need to find a way to deal with any pip present in the environment.

=> Maybe catkin pip should not try to install and setup his own pip, but instead rely on the environment pip to be at a certain version. We could do a simple check from cmake ( until a full 'pip check' feature comes along ).
If that check fails, we should require the user to setup pip as expected by himself ( providing pypa advised commands )

This would mean that catkin_pip relies on pip being there, and able to add other packages ( nose, pytest, etc. ), or at least tell the user to add packages.

Which brings the question, instead of assuming pip would be setup in a specific way, or us setting pip in a specific build folder, isnt it better to let the use do his setup ( system, user or venv ) and catkin_pip uses whatever is available ?

This requires little changes in code, but extensive documentation...

[asmodehn]

Actually, now that catkin_pip manages his own prefix (with latest pip and setuptools), and since the latest is the preferred way to get python dependencies, and with pyup, we have quite a good setup.
catkin_pip relies on system only for the setup of its own prefix, and then everything else derives from there.

Closing this as this seems solved. Better to not tell the user to install any python on system, many people would get it wrong (system-wide pip install, breaking other stuff)