extend python package features

[g-arjones]

Fixes #106 and rock-core/autoproj#313

@moooeeeep Could you please test?

[moooeeeep]

This seems to work for me, thanks!

Any opinions against switching to pip install . --target=#{prefix} or similar (and potentially ditching the explicit build step)?

[g-arjones]

I would prefer not to, for now af least. I'm in the middle of fixing a lot of things (haven't use the python stuff in a while) and I would have to stop to retest and reassess.

Is there a good reason to use pip for that? That's not what I've seen other build tools do.

[g-arjones]

After a quick search it seems we get more control over what happens with setup.py so that's better to integrate. Also pip will try to manage dependencies and I want autoproj to be the tool doing that.

For a user, using pip sounds like a step forward but for a tool I would stick to setup.py

[moooeeeep]

You can avoid having pip download dependencies when you pass the --no-index flag I believe. Then it should only look among the packages that were already downloaded/installed.

Direct invocations of setup.py install are deprecated for more recent versions of setuptools (and further commands might follow). For example this deprecation warning is produced:

/path/to/ws/install/pip/lib/python3.6/site-packages/setuptools/command/install.py:37: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.  setuptools.SetuptoolsDeprecationWarning,

Related issue: #108

This workflow will probably keep working for some time. And if users stick to old versions of pip and setuptools (or rather maintain compatibility with the legacy build system), potentially even longer.
But the presence of an explicit setup.py file is optional these days. If people start to rely on this, define different build backends etc, they will run into problems with autobuild.

Most users will probably want to have their packages pip-installable anyways, so they potentially need to maintain their dependencies in several places. But then again, maybe they could also add their packages as pip osdeps and/or via a custom package index (directory).

For reference:

• https://setuptools.pypa.io/en/latest/build_meta.html
• https://chadsmith-software.medium.com/pep-517-and-518-in-plain-english-47208ca8b7a6
• https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html
• https://packaging.python.org/tutorials/packaging-projects/
• https://packaging.python.org/guides/hosting-your-own-index/
• https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-0

But I agree, this is a bigger topic. And I'm happy to see, that this PR seems to fix the immediate issue #106.

[g-arjones]

I have removed the pytest test utility and left only the fixes for #106 and rock-core/autoproj#313