RFE: add handle --user switch

[wuch-g2v]

Just found that for some bootstrapping from non-root account on packaging for new major python version it would be good to have handle --user switch like pip provides.
In such scenario on bootstrapping when in build env where is installed only python and necessary .whl archives in /usr/share/python-wheels/.

For example on package as rpm package installer bootstrapping could be performed by:

• unpack installer source tree
• install packaging archive /usr/share/python-wheels/packaging-*.whl in user sitelib home directory (by default it is ~/.local/lib/python3.<major_ver>/site-packages with pointing $PYTHONPATH to $PWD/sr
• unpack /usr/share/python-wheels/installer-*.whl in rpm package %{buildroot} with pointing $PYTHONPATH to $PWD/src
• because packaging modules is installed rpm post install dependencies generator which uses packaging is able to generate package provides and requires lists.

Possible to add such feature? 🤔

[eli-schwartz]

I don't understand what you're trying to do at all, but it won't work because rpm isn't going to allow building an rpm package to install things to the --user home directory.

[wuch-g2v]

This procedure which I've sketched is not about rpm used to install/uninstall//upgrade packages but rpmbuild (which is part of the rpm) which is used to build rpm packages.

In other word it is about build procedure implemented in rpm spec file(s) to bootstrap completely new set of rpm packages build on top on new/not used yet major python (like transition from python 3.8.x to 3.9.x).

[eli-schwartz]

because rpm isn't going to allow building an rpm package to install things to the --user home directory

So I stand by my word, they aren't going to allow you to do that. rpm spec files should NOT be writing to the user home directory, whether as a bootstrap process or not.

Bootstrapping usually means building seed packages in a stage X collection of packages, then rebuilding stage X+1 with more features enabled. That means that you'd be building "installer" and "packaging" using an earlier stage that doesn't have the dependencies generator available yet, purely to get to a world where the dependencies generator works.

However I'd also suggest that adding dependency metadata is a pretty trivial problem to solve and not worth adding a new bootstrap stage, so... maybe just manually define metadata for "installer" and "packaging", which is easy because... they don't have any dependencies! :)

[wuch-g2v]

because rpm isn't going to allow building an rpm package to install things to the --user home directory

So I stand by my word, they aren't going to allow you to do that. rpm spec files should NOT be writing to the user home directory, whether as a bootstrap process or not.

Bootstrapping usually means building seed packages in a stage X collection of packages, then rebuilding stage X+1 with more features enabled. That means that you'd be building "installer" and "packaging" using an earlier stage that doesn't have the dependencies generator available yet, purely to get to a world where the dependencies generator works.

However I'd also suggest that adding dependency metadata is a pretty trivial problem to solve and not worth adding a new bootstrap stage, so... maybe just manually define metadata for "installer" and "packaging", which is easy because... they don't have any dependencies! :)

"Manually adding" is not he same as "generating".
Yes it has dependency. Installed in python version sitearch/sitelib directory it depends on that exact python major version.

What I've described is only one of the possibilities.
pip provides installing modules in user home directory and the same would be good to have generally ..