[2024.8.3] SyntaxWarning: invalid escape sequence

[picca]

Hello,

a bunch of warning when installing cctbx on Debian/Ubuntu/Mint/...

this is expected to fail with Python 3.13 if I am not wrong.

Cheers

Setting up python3-cctbx (2024.8+ds2+~3.21.1+ds1-1) ...
/usr/lib/python3/dist-packages/iotbx/pdb/utils.py:8: SyntaxWarning: invalid escape sequence '\{'
  """ Iterator to generate strings of length n_chars, using upper-case,
/usr/lib/python3/dist-packages/iotbx/pdb/utils.py:46: SyntaxWarning: invalid escape sequence '\/'
  special_characters = """[]_,.;:"&<>()\/\{}'`~!@#$%*|+-"""
/usr/lib/python3/dist-packages/xfel/merging/application/errors/error_modifier_mm24.py:777: SyntaxWarning: invalid escape sequence '\o'
  width=pairwise_differences_db, label='$\omega_{hkl}$'
/usr/lib/python3/dist-packages/xfel/merging/application/errors/error_modifier_mm24.py:792: SyntaxWarning: invalid escape sequence '\o'
  axes[0].set_ylabel('Distribution of $\omega_{hbk}$')
/usr/lib/python3/dist-packages/xfel/merging/application/errors/error_modifier_mm24.py:793: SyntaxWarning: invalid escape sequence '\o'
  axes[0].set_xlabel('Normalized PD ($\omega_{hbk}$)')
/usr/lib/python3/dist-packages/xfel/merging/application/errors/error_modifier_mm24.py:812: SyntaxWarning: invalid escape sequence '\o'
  axes[1].set_xlabel('Sorted Normalized PD ($\omega_{hbk}$)')
/usr/lib/python3/dist-packages/xfel/merging/application/errors/error_modifier_mm24.py:831: SyntaxWarning: invalid escape sequence '\s'
  axes[2].set_ylabel('Standard Deviation of $I_{hbk}/\sigma_{hbk}$')
/usr/lib/python3/dist-packages/xfel/merging/application/errors/error_modifier_mm24.py:860: SyntaxWarning: invalid escape sequence '\m'
  axes_sadd.set_ylabel('$s_{\mathrm{fac}}^2 \\times s_{\mathrm{add}}^2$')
Processing triggers for libc-bin (2.40-2) ...

[bkpoon]

This is showing up on our syntax checks for the Python 3.13 release candidates. I'm working on updating our static conda environments and will start testing Python 3.13 soon.

[picca]

Hello, Since you are around. It seems that the conda build is using the script I originaly wrote in order to fix the libtbx config env. Do you know If something was modified. I would like to use the version from the cctbx repository instead of the one in the Debian package. Fred

[bkpoon]

Do you mean the update_libtbx_env.py script?

https://github.com/cctbx/cctbx_project/blob/master/libtbx/auto_build/conda_build/update_libtbx_env.py

That script is specific to conda and their directory structure. If you tell me your directory structure, we can update it to handle that. For example, the Python modules are in a site-packages directory, not dist-packages, but that directory can be exposed as a command-line option.

[picca]

If I remember correctly I wrote this code :)) a few years ago. my question was, could we at some point merge the Debian file with your re-implementation for conda in order to avoid code duplication. and to have this script available for others. Cheers Fred

[bkpoon]

Is the script in the Debian fork under the "debian" directory?

https://salsa.debian.org/science-team/cctbx/-/blob/master/debian/update_libtbx_env.py?ref_type=heads

It looks like you added the file to that directory in 2022 (https://salsa.debian.org/science-team/cctbx/-/commit/fc5efd8e334f5674dc5a96940d19d3e69a34454d).

I have the file in our commit history since 2020 (990ba48). 😄

I had to create this to put things in the right place for the conda package. It looks like the non-linux platform things were removed.

Some questions for integration,

1. Do you build this for different versions of Python and then have the libtbx environment file in a directory for that specific version of Python ('--dest-dir` flag)?
2. How are the command line tools structured in the Debian installations? We have "dispatchers" that will set things like PYTHONPATH in our development builds. The conda packages do not have that and will actively unset those kinds of environment variables. We also prepend the 'bin' directory from the conda environment in PATH so that the conda environment binaries take precedence. Also, that generally lets us run the code without "activating" the conda environment. If we eventually have some conda dependency that does some extra stuff during environment activation, the extra activation steps can be added into our dispatchers as well.

The timeline for merging the 2 scripts would be later this year or next year.

[bkpoon]

I forgot to mention that we are compatible with Boost 1.86 and Numpy 2. For Boost, you would need the Numpy 2 patches here (https://github.com/conda-forge/boost-feedstock/tree/v1.84.x/recipe/patches, the main branch is currently 1.86, but the Numpy 2 patches were also applied to 1.84).

[picca]

Hello, In fact I remember now, I need and exemple of update of the config part. So I found your code, and then implement the logic. If I remember correctly :).

Nevertheless, do you think that the Debian version could be merged with your version ?

The best would be to get rid of the specific build system on top of scons.

1. Yes I build for different version of Pyton and the pickle object is store in different directory for each version.
   https://sources.debian.org/src/cctbx/2024.8+ds2+~3.21.1+ds1-1/debian/patches/libtbx_env-per-python-version.patch/

2. for the scripts, I use the generated dispatched files. How do go generate the version without the dispatcher ?
   To my opinion, all this should be entry points.

The numpy2 patch is already applyed to the upstream in order to suport numpy1 and numpy2 ?