Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python:: local installation of python client/bindings #1641

Closed
adriansev opened this issue Mar 11, 2022 · 21 comments
Closed

python:: local installation of python client/bindings #1641

adriansev opened this issue Mar 11, 2022 · 21 comments

Comments

@adriansev
Copy link
Contributor

Hi! After the new improvements the recipe for local installation from local repository no longer works. What is the new procedure for local python bindings install? Note that the need is to also test uncommitted source modifications.
what i tried so far is:

python3 -m pip install --user -U git+file:///home/adrian/GIT-REPOS/xrootd
python3 -m pip install --user -U git+file:///home/adrian/GIT-REPOS/xrootd/python
python3 -m pip install --user -U git+file:///home/adrian/GIT-REPOS/xrootd/python/bindings
@simonmichal
Copy link
Contributor

@matthewfeickert : could you please comment on this one (we really do appreciate your time and help!)

@adriansev
Copy link
Contributor Author

adriansev commented Mar 11, 2022

oh, also, our build recipe is no longer working, in the sense that, python bindings are no longer found by our python installation

@adriansev
Copy link
Contributor Author

more info: so this is the build log and i noticed this:

Installing collected packages: xrootd
  Attempting uninstall: xrootd
    Found existing installation: xrootd 5.4.1
ERROR: Cannot uninstall 'xrootd'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.

which is wrong as this should not see the system (or user side) installation ..

@matthewfeickert
Copy link
Contributor

I will not have time to look at this seriously until after Snowmass white papers are submitted. As always, minimal reproducible examples are nice, so please provide one.

@matthewfeickert
Copy link
Contributor

matthewfeickert commented Mar 11, 2022

Though to provide you something from #1594 (comment)

$ docker run --rm -ti xrootd/xrootd:issue-1594
[root@9cc1f196bef4 /]# . /opt/rh/devtoolset-7/enable
[root@9cc1f196bef4 /]# python3 -m venv issue-1641
[root@9cc1f196bef4 /]# . issue-1641/bin/activate
(issue-1641) [root@9cc1f196bef4 /]# python -m pip --quiet install --upgrade pip setuptools wheel   
Cache entry deserialization failed, entry ignored
(issue-1641) [root@9cc1f196bef4 /]# python -m pip --quiet install --upgrade build
(issue-1641) [root@9cc1f196bef4 /]# cd xrootd/
(issue-1641) [root@9cc1f196bef4 xrootd]# cp packaging/wheel/* .
(issue-1641) [root@9cc1f196bef4 xrootd]# python -m build --sdist .
...
Successfully built xrootd-unknown.tar.gz
(issue-1641) [root@9cc1f196bef4 xrootd]# cd ..  # Move xrootd.egg-info off PYTHONPATH
(issue-1641) [root@9cc1f196bef4 /]# python -m pip install --upgrade xroot/dist/xrootd-unknown.tar.gz 
Processing ./dist/xrootd-unknown.tar.gz
  Preparing metadata (setup.py) ... done
Building wheels for collected packages: xrootd
  Building wheel for xrootd (setup.py) ... done
  WARNING: Legacy build of wheel for 'xrootd' created no files.
  Command arguments: /issue-1641/bin/python -u -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-req-build-m80_htkl/setup.py'"'"'; __file__='"'"'/tmp/pip-req-build-m80_htkl/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-9yheewvo
  Command output: [use --verbose to show]
  Running setup.py clean for xrootd
Failed to build xrootd
Installing collected packages: xrootd
    Running setup.py install for xrootd ... done
Successfully installed xrootd-5.4.2
(issue-1641) [root@9cc1f196bef4 /]# python -m pip show xrootd
WARNING: No metadata found in /issue-1641/lib/python3.6/site-packages
WARNING: No metadata found in /issue-1641/lib/python3.6/site-packages
WARNING: No metadata found in /issue-1641/lib/python3.6/site-packages
Name: xrootd
Version: 5.4.2
Summary: 
Home-page: 
Author: 
Author-email: 
License: 
Location: /issue-1641/lib/python3.6/site-packages
Requires: 
Required-by: 

this is the exact thing done in the CI:

- name: Build sdist using publishing workflow
run: |
. /opt/rh/devtoolset-7/enable
cp packaging/wheel/* .
./publish.sh
cd .. # Move xrootd.egg-info off PYTHONPATH
python3 -m pip --verbose install xrootd/dist/xrootd-*.tar.gz
python3 -m pip list

You could have done the same thing outside a venv too

(issue-1641) [root@9cc1f196bef4 xrootd]# deactivate
[root@9cc1f196bef4 xrootd]# python3 -m pip --quiet install --upgrade pip setuptools wheel
[root@9cc1f196bef4 xrootd]# cd ..  # Move xrootd.egg-info off PYTHONPATH
[root@9cc1f196bef4 /]# python3 -m pip install --upgrade --user xroot/dist/xrootd-unknown.tar.gz
Processing ./dist/xrootd-unknown.tar.gz
  Preparing metadata (setup.py) ... done
Building wheels for collected packages: xrootd
  Building wheel for xrootd (setup.py) ... done
  WARNING: Legacy build of wheel for 'xrootd' created no files.
  Command arguments: /usr/bin/python3 -u -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-req-build-3ajy3hoe/setup.py'"'"'; __file__='"'"'/tmp/pip-req-build-3ajy3hoe/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-44hqsp87
  Command output: [use --verbose to show]
  Running setup.py clean for xrootd
Failed to build xrootd
Installing collected packages: xrootd
    Running setup.py install for xrootd ... done
Successfully installed xrootd-5.4.2
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
[root@9cc1f196bef4 /]# python3 -m pip show xrootd
WARNING: No metadata found in /root/.local/lib/python3.6/site-packages
WARNING: No metadata found in /root/.local/lib/python3.6/site-packages
WARNING: No metadata found in /root/.local/lib/python3.6/site-packages
Name: xrootd
Version: 5.4.2
Summary: 
Home-page: 
Author: 
Author-email: 
License: 
Location: /root/.local/lib/python3.6/site-packages
Requires: 
Required-by: 

@adriansev
Copy link
Contributor Author

@matthewfeickert so, sorry if i was not very clear: i was asking for a recipe for local installation as the old one no longer works. in my first post i put a link to the recipe that used to work when being run from the root of repository, and my question was, how can that be replaced. the second problem relates to the ALICE software building, and if you want i can provide you with the recipe, but first we have to establish why there is that "cannot uninstall error"

@adriansev
Copy link
Contributor Author

@matthewfeickert thanks a lot! so, i just successfully tried your recipe:

python3 -m pip --quiet install --upgrade build
command cp -f -r packaging/wheel/* .
python -m build --sdist .
python3 -m pip install --upgrade dist/xrootd-unknown.tar.gz

the package was installed:

pip3 freeze | grep xrootd
xrootd==5.4.2

but the problem is that i have this:

ALIBUILD##[Friday 11.03.22 18:34] adrian@hal : ~/work-GRID/xrootd  ((v5.4.2)) $ 
python3 -c 'from XRootD import client as xrd_client;import logging;print(xrd_client.__version__);'
unknown

any idea how this can be fixed? prior, this used to be either the git tag, or the date followed by - and the short hash of the head

@matthewfeickert
Copy link
Contributor

matthewfeickert commented Mar 11, 2022

but the problem is that i have this:

ALIBUILD##[Friday 11.03.22 18:34] adrian@hal : ~/work-GRID/xrootd  ((v5.4.2)) $ 
python3 -c 'from XRootD import client as xrd_client;import logging;print(xrd_client.__version__);'
unknown

any idea how this can be fixed? prior, this used to be either the git tag, or the date followed by - and the short hash of the head

Sure. To get the version too just run the publish.sh script to build the sdist that you then pip install (so basically follow the CI exactly:

- name: Build sdist using publishing workflow
run: |
. /opt/rh/devtoolset-7/enable
cp packaging/wheel/* .
./publish.sh
cd .. # Move xrootd.egg-info off PYTHONPATH
python3 -m pip --verbose install xrootd/dist/xrootd-*.tar.gz
python3 -m pip list

)

publish.sh determines the version and then injects it for the build

./genversion.sh
version=$(./genversion.sh --print-only)
version=${version#v}
echo $version > bindings/python/VERSION

@matthewfeickert
Copy link
Contributor

matthewfeickert commented Mar 11, 2022

By the way, that

cd ..  # Move xrootd.egg-info off PYTHONPATH

before you pip install to wherever can be important if you are on a system where the versions of setuptools are capped. So while maybe not always needed, probably worth doing. I forgot to add that at first.

c.f. 2cc617c and #1604 (comment) for more details here.

Also unless you're on a system with setuptools newer than v0.60.0, you'll need to keep the

rm -rf ~/.local/lib/python*/site-packages/{XRootD,pyxrootd,xrootd*}

line in your xrootdpy_rebuild recipe as even if you do

python -m pip uninstall xrootd

that will only get the site-packages/xrootd. Luckily with modern setuptools everything is nicely dealt with and so for setuptools v0.60.0+ you can just

python -m pip uninstall xrootd

Though this requires Python 3.7 or later.

@adriansev
Copy link
Contributor Author

@matthewfeickert thanks!! yeah, i noticed that and followed, and i can confirm that with on a tagged head i get the valid result.
but, i also tried the master and i got this:

Successfully built xrootd-2022.310.tar.gz
Processing ./xrootd/dist/xrootd-20220310-3fae8a870-.tar.gz
  Preparing metadata (setup.py) ... done
Processing ./xrootd/dist/xrootd-2022.310.tar.gz
  Preparing metadata (setup.py) ... done
ERROR: Cannot install xrootd 2022.310 (from /home.hdd/adrian/work-GRID/xrootd/dist/xrootd-2022.310.tar.gz) and xrootd 2022.310 (from /home.hdd/adrian/work-GRID/xrootd/dist/xrootd-20220310-3fae8a870-.tar.gz) because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested xrootd 2022.310 (from /home.hdd/adrian/work-GRID/xrootd/dist/xrootd-20220310-3fae8a870-.tar.gz)
    The user requested xrootd 2022.310 (from /home.hdd/adrian/work-GRID/xrootd/dist/xrootd-2022.310.tar.gz)

and i see in dist :

ALIBUILD##[Friday 11.03.22 19:08] adrian@hal : ~/work-GRID/xrootd  (master) $ 
ls -l dist
total 6432
-rw-rw-r-- 1 adrian adrian 3292627 2022/Mar/11 19:07:05 xrootd-20220310-3fae8a870-.tar.gz
-rw-rw-r-- 1 adrian adrian 3291024 2022/Mar/11 19:07:11 xrootd-2022.310.tar.gz

just i case i messed up the instructions, this is the current script that i use for building: https://github.com/adriansev/bin-scripts/blob/master/xrootdpy_rebuild

Thank you!!

@matthewfeickert
Copy link
Contributor

matthewfeickert commented Mar 11, 2022

but, i also tried the master and i got this:

Successfully built xrootd-2022.310.tar.gz
Processing ./xrootd/dist/xrootd-20220310-3fae8a870-.tar.gz
  Preparing metadata (setup.py) ... done
Processing ./xrootd/dist/xrootd-2022.310.tar.gz
  Preparing metadata (setup.py) ... done
ERROR: Cannot install xrootd 2022.310 (from /home.hdd/adrian/work-GRID/xrootd/dist/xrootd-2022.310.tar.gz) and xrootd 2022.310 (from /home.hdd/adrian/work-GRID/xrootd/dist/xrootd-20220310-3fae8a870-.tar.gz) because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested xrootd 2022.310 (from /home.hdd/adrian/work-GRID/xrootd/dist/xrootd-20220310-3fae8a870-.tar.gz)
    The user requested xrootd 2022.310 (from /home.hdd/adrian/work-GRID/xrootd/dist/xrootd-2022.310.tar.gz)

and i see in dist :

ALIBUILD##[Friday 11.03.22 19:08] adrian@hal : ~/work-GRID/xrootd  (master) $ 
ls -l dist
total 6432
-rw-rw-r-- 1 adrian adrian 3292627 2022/Mar/11 19:07:05 xrootd-20220310-3fae8a870-.tar.gz
-rw-rw-r-- 1 adrian adrian 3291024 2022/Mar/11 19:07:11 xrootd-2022.310.tar.gz

This is just because you're asking pip to install multiple versions of the same package with

python3 -m pip install --user --upgrade ${BNAME}/dist/xrootd-*.tar.gz

as you have multiple sdists under dist/ that start their name with xrootd. If you want to use xrootd-*.tar.gz then you'll need to cleanup / delete the contents of dist before you build a new sdist with build.

It looks like you're trying to do that here, but I think you're in the wrong directory(?). Also publish.sh already builds the sdist

python3 -m build --sdist .

so you can remove this line.

Probably easier to just do

# ...
python3 -m pip --quiet install --upgrade build
command cp -f -r packaging/wheel/* .
rm dist/*
./publish.sh

cd ..
python3 -m pip install --user --upgrade ${BNAME}/dist/xrootd-*.tar.gz
# ...

@adriansev
Copy link
Contributor Author

@matthewfeickert thanks a lot! yes, it seems that the second bdist line was wrong.
at this moment i can build also master, and now that i have the examples from build.yml i can see how can i adapt our build recipes.
So, just for confirmation, looking at the recipe https://github.com/xrootd/xrootd/blob/v5.4.2/.github/workflows/build.yml#L100
should the python bindings will be automatically be found in CMAKE_INSTALL_PREFIX/lib/python${PYTHON_VERSION}/site-packages ?

now, on the matter of normal cmake based xrootd installation https://github.com/alisw/alidist/blob/master/xrootd.sh#L49
it seems that there is a mismatch of sorts between what python should see ..
in the log here: https://asevcenc.web.cern.ch/asevcenc/alibuild_xrootd542/log
i get:

-- Processing: //home/physics-tools/alicebuild/sw/fedora35_x86-64/XRootD/xrootd-local2/share/man/man1/xrdmapc.1
Processing ./bindings/python
  Preparing metadata (setup.py): started
  Preparing metadata (setup.py): finished with status 'done'
Building wheels for collected packages: xrootd
  Building wheel for xrootd (setup.py): started
  Building wheel for xrootd (setup.py): finished with status 'done'
  Created wheel for xrootd: filename=xrootd-2022.310+3fae8a870-cp310-cp310-linux_x86_64.whl size=1492763 sha256=e4185db69b3c5f580864925e1236773cc63376870789c70d0b19bc29782919e3
  Stored in directory: /home/physics-tools/alicebuild/xrootd/tmp/pip-ephem-wheel-cache-raoegz6i/wheels/ce/0c/a2/89fae19e44d0efe6e789006aab5941f99901c4b09d7843f92c
Successfully built xrootd
Installing collected packages: xrootd
  Attempting uninstall: xrootd
    Found existing installation: xrootd 5.4.1
ERROR: Cannot uninstall 'xrootd'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.
++ popd
/home/physics-tools/alicebuild/sw/BUILD/1a865e68f28dfe14782f80089dbddcdf3ec15076/XRootD

and this should not happen, as ideally nor the system installed python(and packages) nor user installed packages should be seen... this happens in an environment that have it's own python. until this is fixed in xrootd, is there anything that we can do to intercept and fix the problem? Maybe something like build without python, and then build/install the python bindings based on what we just compiled, but with our python infrastructure and locations?

Thanks a lot!

@adriansev
Copy link
Contributor Author

@matthewfeickert so, i found the problem and the solution was this:
https://github.com/adriansev/alidist/blob/xrootd_update/xrootd.sh#L47
would there be any problems to have this in xrootd?
Thank you!

@matthewfeickert
Copy link
Contributor

matthewfeickert commented Mar 11, 2022

So, just for confirmation, looking at the recipe https://github.com/xrootd/xrootd/blob/v5.4.2/.github/workflows/build.yml#L100 should the python bindings will be automatically be found in CMAKE_INSTALL_PREFIX/lib/python${PYTHON_VERSION}/site-packages ?

Correct. As an explicit example with the image built from this Dockerfile located at docker/centos7/Dockerfile in the XRootD repo which installs the Python bindings during the CMake build with CMAKE_INSTALL_PREFIX=/usr/local/

Dockerfile:
ARG BASE_IMAGE=gitlab-registry.cern.ch/linuxsupport/cc7-base:latest
FROM ${BASE_IMAGE} as base

SHELL [ "/bin/bash", "-c" ]

RUN yum update -y && \
    yum install -y \
        cmake3 \
        make \
        krb5-devel \
        libuuid-devel \
        libxml2-devel \
        openssl-devel \
        systemd-devel \
        zlib-devel \
        devtoolset-7-gcc-c++ \
        python3-devel \
        python3-setuptools \
        git \
        cppunit-devel && \
    yum clean all && \
    python3 -m pip install --no-cache-dir --upgrade pip setuptools wheel

COPY . /code/xrootd

WORKDIR /code
RUN source scl_source enable devtoolset-7 && \
    cmake3 \
        -DCMAKE_INSTALL_PREFIX=/usr/local/ \
        -DPYTHON_EXECUTABLE=$(command -v python3) \
        -DENABLE_TESTS=ON \
        -DPIP_VERBOSE=ON \
        -S xrootd \
        -B build && \
    cmake3 build -LH && \
    cmake3 \
        --build build \
        --clean-first \
        --parallel $(($(nproc) - 1)) && \
    cmake3 --build build --target install && \
    cd / && \
    python3 -m pip list

WORKDIR /

SHELL [ "/usr/bin/scl", "enable", "devtoolset-7", "/bin/bash", "-c"]

if you build it with

docker build . --file docker/centos7/Dockerfile --tag xrootd/xrootd:centos7

then you can see that the bindings got installed under the /usr/local/ site-packages as expected:

$ docker run --rm xrootd/xrootd:centos7 /bin/bash -c 'python3 -m pip show xrootd'
Name: xrootd
Version: unknown
Summary: XRootD Python bindings
Home-page: http://xrootd.org
Author: XRootD Developers
Author-email: xrootd-dev@slac.stanford.edu
License: LGPLv3+
Location: /usr/local/lib64/python3.6/site-packages
Requires: 
Required-by: 

now, on the matter of normal cmake based xrootd installation https://github.com/alisw/alidist/blob/dd7ddacd743649bf9ca06af474275d2551a5a80c/xrootd.sh#L49 it seems that there is a mismatch of sorts between what python should see .. in the log here: https://asevcenc.web.cern.ch/asevcenc/alibuild_xrootd542/log i get:

-- Processing: //home/physics-tools/alicebuild/sw/fedora35_x86-64/XRootD/xrootd-local2/share/man/man1/xrdmapc.1
Processing ./bindings/python
  Preparing metadata (setup.py): started
  Preparing metadata (setup.py): finished with status 'done'
Building wheels for collected packages: xrootd
  Building wheel for xrootd (setup.py): started
  Building wheel for xrootd (setup.py): finished with status 'done'
  Created wheel for xrootd: filename=xrootd-2022.310+3fae8a870-cp310-cp310-linux_x86_64.whl size=1492763 sha256=e4185db69b3c5f580864925e1236773cc63376870789c70d0b19bc29782919e3
  Stored in directory: /home/physics-tools/alicebuild/xrootd/tmp/pip-ephem-wheel-cache-raoegz6i/wheels/ce/0c/a2/89fae19e44d0efe6e789006aab5941f99901c4b09d7843f92c
Successfully built xrootd
Installing collected packages: xrootd
  Attempting uninstall: xrootd
    Found existing installation: xrootd 5.4.1
ERROR: Cannot uninstall 'xrootd'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.
++ popd
/home/physics-tools/alicebuild/sw/BUILD/1a865e68f28dfe14782f80089dbddcdf3ec15076/XRootD

and this should not happen, as ideally nor the system installed python(and packages) nor user installed packages should be seen... this happens in an environment that have it's own python. until this is fixed in xrootd...

I don't think there's anything to fix here. The pip error message explains things correctly. It seems that the v5.4.1 version was installed using distuils through a direct invocation of python setup.py install and not through pip plus setuptools.

c.f. pypa/pip#5247 (comment) for a concise technical summary from the PyPA on why errors like this happen.

This is strange though, as this sort of thing is what motivated me to open up Issue #1579 in the first place and make the changes that went into v5.4.1.

I'm a bit confused too why v5.4.1 is showing up in your build logs, as you updated to v5.4.0 in alisw/alidist#3696 and are now trying to update from v5.4.0 to v5.4.2 in alisw/alidist#3933. This makes sense to me why you're seeing the distuils error given that v5.4.0 was installed with the deprecated python setup.py install and distutils pattern, and now v5.4.2 is using the pip + setuptools approach and so rightly complaining that it is lacking enough information to know how to remove the v5.4.0 distutils based install. But you're showing v5.4.1 and not v5.4.0 in the logs. :? Can you explain what is happening here?

...is there anything that we can do to intercept and fix the problem?

The short answer is just manually delete the old distuitls directory (the PyPA approach in pypa/pip#5247 (comment)), but ...

Maybe something like build without python, and then build/install the python bindings based on what we just compiled, but with our python infrastructure and locations?

...yes this will also indeed work. c.f. #1594 (comment) for an example of building with CMake and then installing the Python bindings from PyPI.

@adriansev
Copy link
Contributor Author

in my case 5.4.1 is distro installed, also usually i have another --user installed version for testing, and the ALICE software that is built is completely another matter that always was distinct from any system present software. So, with this context, what solution do you see? i'm not familiar with intricacies of python building, i'm just trying to make things work. thank you!

@adriansev
Copy link
Contributor Author

adriansev commented Mar 12, 2022

also, related to #1594 (comment) is there a solution to use the already present source? can i do python -m pip install git+file://${BUILDDIR}/some_directory (where BUILDDIR is a copy of git repository) ?

@matthewfeickert
Copy link
Contributor

in my case 5.4.1 is distro installed, also usually i have another --user installed version for testing, and the ALICE software that is built is completely another matter that always was distinct from any system present software. So, with this context, what solution do you see?

Ah okay. Thanks for explaining. So let me see if I have this all correct.

Okay, so if I have that all right, then it seems that you're trying to mix installing Python packages from package managers and from pip but not placing them in distinct places and installing both globally(?). The short answer is that Python applications / libraries are not designed to be mixed like this and you'll need to choose one or the other. If you're going to use a package manger like yum to install Python bindings to compiled applications that's fine (and something I would recommend), but then you should leave these globally installed applications to the package manager and use Python virtual environments to install Python packages and applications at a local level. If you truly need Python bindings installed globally from pip and not from a package manager, then my recommendation is to use pipx. I'm sure that you'll have questions on this, which is fine and great, but I may enlist @henryiii to give you some relevant blog posts to follow up on.

Okay, assuming I have that right (my apologies if not) my recommendation for the v5.4.1 problem is the following:

  • Use whatever package manager (I'm assuming yum?) to install v5.4.2 uninstalling v5.4.1 along the way. Just use your package manager to get XRootD and its Python bindings (though maybe you can't for good reasons).
  • For local testing, use a Python virtual environment instead of --user. This is safer, much easier to manage, and allows you to have an unlimited number of versions to test against, mess around with, compared to only having one version that is installed with --user.

Does this seem reasonable? Sorry if I've confused the situation or missed anything.

also, related to #1594 (comment) is there a solution to use the already present source?

You could use the current source that you have, but you'd need to do the

- name: Build sdist using publishing workflow
run: |
. /opt/rh/devtoolset-7/enable
cp packaging/wheel/* .
./publish.sh
cd .. # Move xrootd.egg-info off PYTHONPATH
python3 -m pip --verbose install xrootd/dist/xrootd-*.tar.gz
python3 -m pip list
sort of system. At that point it is probably just easier to install from PyPI, unless you're trying to match source versions exactly.

can i do python -m pip install git+file://${BUILDDIR}/some_directory (where BUILDDIR is a copy of git repository) ?

Currently no. The pattern that you describe here with being able to install from Git repos is a very reasonable one, but that requires the repository structure to be setup in a way that allows for that. The XRootD system is setup in a way that requires you to do the

- name: Build sdist using publishing workflow
run: |
. /opt/rh/devtoolset-7/enable
cp packaging/wheel/* .
./publish.sh
cd .. # Move xrootd.egg-info off PYTHONPATH
python3 -m pip --verbose install xrootd/dist/xrootd-*.tar.gz
python3 -m pip list

sort of workflow as the cp moves specific files to locations. I agree with you that it would be nicer if this wasn't necessary, but I didn't attempt to tackle that when I was trying to update things for v5.4.1 as that seemed larger/out of scope. I think a GitHub Issue for this idea would be really nice though!

@matthewfeickert
Copy link
Contributor

As a follow up, here's a Dockerfile where I've intentionally recreated the problem you describe, and then show how to get around it if you decided you need to install Python bindings globally with pip.

Dockerfile:
ARG BASE_IMAGE=gitlab-registry.cern.ch/linuxsupport/cc7-base:latest
FROM ${BASE_IMAGE} as base

SHELL [ "/bin/bash", "-c" ]

RUN yum update -y && \
    yum install -y \
        cmake3 \
        make \
        krb5-devel \
        libuuid-devel \
        libxml2-devel \
        openssl-devel \
        systemd-devel \
        zlib-devel \
        devtoolset-7-gcc-c++ \
        python3-devel \
        python3-setuptools \
        git \
        cppunit-devel && \
    yum clean all && \
    python3 -m pip install --no-cache-dir --upgrade pip setuptools wheel

RUN yum update -y && \
    yum install -y \
        xrootd-5.4.1 \
        xrootd-client-5.4.1 \
        python36-xrootd-5.4.1 && \
    yum clean all && \
    xrootd -v && \
    xrdcp --version && \
    python3 -m pip list && \
    python3 -m pip show xrootd  # 5.4.1

# The following would fail with the error:
#
# ERROR: Cannot uninstall 'xrootd'. It is a distutils installed project and thus we
# cannot accurately determine which files belong to it which would lead to only a
# partial uninstall.
#
# as you're asking pip to try to deal with something it didn't install.

# RUN . /opt/rh/devtoolset-7/enable && \
#     python3 -m pip install --upgrade --force-reinstall 'xrootd==5.4.2' && \
#     xrootd -v && \
#     xrdcp --version && \
#     python3 -m pip list && \
#     python3 -m pip show xrootd

# The solution is to uninstall the RPM package and _then_ to install things
# A better solution is to not be installing Python packages globally as pip
# warns us about:
#
# WARNING: Running pip as the 'root' user can result in broken permissions and
# conflicting behaviour with the system package manager. It is recommended to
# use a virtual environment instead: https://pip.pypa.io/warnings/venv
#
# and to instead either use an automatically activated virtual envrionment or to
# use pipx

RUN yum remove python36-xrootd -y && \
    . /opt/rh/devtoolset-7/enable && \
    python3 -m pip --verbose install \
        --upgrade \
        --force-reinstall \
        'xrootd==5.4.2' && \
    xrootd -v && \
    xrdcp --version && \
    python3 -m pip list && \
    python3 -m pip show xrootd && \
    python3 -c 'import XRootD; print(XRootD)' && \
    python3 -c 'import pyxrootd; print(pyxrootd)' && \
    python3 -c 'from XRootD import client; print(client.FileSystem("root://someserver:1094"))'

WORKDIR /

SHELL [ "/usr/bin/scl", "enable", "devtoolset-7", "/bin/bash", "-c"]

the commented out snippet

RUN . /opt/rh/devtoolset-7/enable && \
    python3 -m pip install --upgrade --force-reinstall 'xrootd==5.4.2' && \

snippet fails with your error:

ERROR: Cannot uninstall 'xrootd'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.

The part that allows the build to succeed is the bit below where the rpm is first removed to avoid collisions like this that pip has no way of being able to solve

RUN yum remove python36-xrootd -y && \
    . /opt/rh/devtoolset-7/enable && \
    python3 -m pip --verbose install \
        --upgrade \
        --force-reinstall \
        'xrootd==5.4.2' && \
    ...

Does this all make sense?

@adriansev
Copy link
Contributor Author

So, for the record (as a lot was settled in private communication) a short summary with context, problem and workable solution for us (ALICE) is the following:

  1. Context: one can have a system install xrootd python bindings (beside the --user installed one). the ALICE building framework, builds and install all it's software (including all python infrastructure) into it's own locations.

  2. Problem: the running of installation command for python bindings (https://github.com/xrootd/xrootd/blob/v5.4.2/bindings/python/CMakeLists.txt#L93) was throwing the error:

Installing collected packages: xrootd
  Attempting uninstall: xrootd
    Found existing installation: xrootd 5.4.1
ERROR: Cannot uninstall 'xrootd'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.

this 5.4.1 being the system level installed package.

  1. the solution was to modify https://github.com/xrootd/xrootd/blob/v5.4.2/bindings/python/CMakeLists.txt#L95
    and add --ignore-installed (the simplest reason being that the name of argument seemed to imply what i wanted for the install to do)

moreover, maybe part of the context, i should mention that on clusters, or any multi-user machines, that xrootd might be needed system-level and this should not hinder the ALICE users to build the ALICE software;
moreover, while technically maybe possible, it's not in current mainstream/upstream usage the use of python venv (so, if i do so, i'm on my own, maybe i could manage, but here were are talking about ALL ALICE users that build the software); more so, implementation of pipx should be done by building framework developers, but among the current things, the priority for such a thing is really low..

@simonmichal
Copy link
Contributor

@adriansev & @matthewfeickert : could you just quickly let me know what is the status of this one? is it covered by #1648?

@adriansev
Copy link
Contributor Author

this was answered and the actual recipe look like this: https://github.com/adriansev/bin-scripts/blob/e6d2b4a857e4f1876864853b9917faca17d5ed21/xrootdpy_rebuild#L13

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants