Some background
The suds-jurko package used by DIRAC was a fork of the original suds package. At some point suds-jurko stopped being maintained and now suds-community has been created. The suds-community package has now gained access to the original suds name on PyPI are currently releasing under both names. When suds 2.0.0 is released they intend to stop using suds-community and only use suds. All three of this packages provide a import suds which behaves similarlly.
Why is the is a problem for DIRAC
For Python 3 releases of DIRAC we install using pip. This results in pip resolving all dependencies and installing any packages which are missing. As we almost always install on top of DIRACOS pip install doesn't actually end up installing any dependencies.
As suds-jurko/suds-community/suds have different names pip thinks they're all totally unrelated packages (as the import name(s) is/are independent of the package name). We can change DIRAC to depend on suds however in DIRACOS2 we can't provide both as they use the same import name (i.e. files) and will "clobber" each other. We also can't let pip install suds-jerko as setuptools dropped support for the use_2to3 flag about a year ago and pip install suds-jerko no longer works.
Proposed solution
- Depend on
suds in rel-v7r2/rel-v7r3/integration
- To make
pip think that suds-jerko is already installed we can add a conda package (suds-jurko-compat) which provides a suds-jerko package but which actually depends on suds. This will set up the Python package metadata for suds-jerko without needing to have multiple packages clobbering each other.
Implementation
Some background
The
suds-jurkopackage used by DIRAC was a fork of the originalsudspackage. At some pointsuds-jurkostopped being maintained and nowsuds-communityhas been created. Thesuds-communitypackage has now gained access to the originalsudsname on PyPI are currently releasing under both names. Whensuds 2.0.0is released they intend to stop usingsuds-communityand only usesuds. All three of this packages provide aimport sudswhich behaves similarlly.Why is the is a problem for DIRAC
For Python 3 releases of DIRAC we install using
pip. This results inpipresolving all dependencies and installing any packages which are missing. As we almost always install on top of DIRACOSpip installdoesn't actually end up installing any dependencies.As
suds-jurko/suds-community/sudshave different namespipthinks they're all totally unrelated packages (as theimportname(s) is/are independent of the package name). We can change DIRAC to depend onsudshowever in DIRACOS2 we can't provide both as they use the same import name (i.e. files) and will "clobber" each other. We also can't let pip installsuds-jerkoas setuptools dropped support for theuse_2to3flag about a year ago andpip install suds-jerkono longer works.Proposed solution
sudsinrel-v7r2/rel-v7r3/integrationpipthink thatsuds-jerkois already installed we can add a conda package (suds-jurko-compat) which provides asuds-jerkopackage but which actually depends onsuds. This will set up the Python package metadata forsuds-jerkowithout needing to have multiple packages clobbering each other.Implementation
suds-jurko-compatrecipe Add suds-jurko-compat metapackage management#56suds-jurko-compatto thediracgridchannelsuds/suds-jurko-compatto DIRACOS2 Replace suds-jurko with suds DIRACOS2#77sudsinrel-v7r2[v7r2] Replace suds-jurko with suds #6323sudsinrel-v7r3[v7r3] Replace suds-jurko with suds #6324sudsinintegration[8.0] Replace suds-jurko with suds #6298