Hello,

ATLAS is looking into installing standalone Docker Images for its software releases and for that we'd like to install the panda clients in them. Can yo document the software dependencies (and dependencies on things like EGI trust anchors etc? A while back we had a prototype, but i'm not sure if the EGI things are still applicable

https://github.com/lukasheinrich/asg-docker/blob/master/preasg-base/Dockerfile

Thanks,
Lukas

With rucio scoping patterns scope:datasetname using such a dataset as a secondary dataset seems to break since prun splits on ':'

I craeted this test

prun --exec "echo %IN; echo %HELLO; find ." --inDS user.lheinric:multiDStest1 --secondaryDS HELLO:1:user.lheinric:multiDStest1.secondary --outDS user.lheinric:multiDStest.out.v2 --forceStaged --site ANALY_MANC_GPU_TEST --noBuild

https://bigpanda.cern.ch/task/16164344/

In this line

https://github.com/PanDAWMS/panda-client/blob/master/pandatools/AthenaUtils.py#L1062

buildDir = os.path.dirname(buildDir.split(':')[0])

exactly value [0] is taken as the buildDir. CMAKE_PREFIX_PATH is a variable that some users modify and this is very risky. In particular as it leads to very inscrutable behaviour when used within prun. Isn't there a better way of determining the user's build directory?

I only found this issue after many hours of debugging. I started from grid jobs that failed with the error

TBufferFile::ReadObject   ERROR   trying to read an emulated class (AnalysisBase_VHbb) to store in a compiled pointer (EL::Algorithm)

Since there was only a limited reaction on the corresponding ATLAS e-mail thread, I thought it would be better to open an issue here.

The following way of calling CPack is way "over engineered". 😦

https://github.com/PanDAWMS/panda-client/blob/master/pandaclient/AthenaUtils.py#L1067-L1070

Most of the -D arguments are unnecessary in there. But there is one that is actively disruptive: -D CPACK_INSTALL_CMAKE_PROJECTS="" That one explicitly tells CPack not to install anything.

With the way that AtlasCMake has operated for years, this option was simply ignored. But now that I'm trying to make the ATLAS builds behave in a "more standard" way, this flag prevents prun from collecting the code of the users that they are trying to execute a job with.

Please remove that argument from the CPack call. It was not needed with old ATLAS analysis releases either, and is now actively hurtful with the latest ones.

Hi @tmaeno ,

I see that the panda-client is already equipped with a setup.py file. Can we just push the release to PyPi so that we can do

pip install panda-client

The only thing you would need to do is make a PyPI account and

python setup.py sdist upload

Best,
Lukas

As noted in PR #20:

In the sdist creation phase of the build there is currently the warning:

$ python setup.py sdist
/home/runner/work/panda-client/panda-client/setup.py:6: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
  import distutils
...

The use of distutils in setup.py

should be replaced with setuptools commands.