4 ms·

In Spack [1] we can express all these constraints for the dependency solver, and we also try to always re-cythonize sources [2]. The latter is because bundled c

In Spack [1] we can express all these constraints for the dependency solver, and we also try to always re-cythonize sources [2]. The latter is because bundled cythonized files are sometimes forward incompatible with Python, so it's better to just regenerate those with an up to date cython. [1] https://github.com/spack/spack/ https://github.com/spack/spack/ [2] https://github.com/spack/spack/pull/35995 https://github.com/spack/spack/pull/35995

x3n0ph3n3 3y ago
Oh great, yet _another_ Python package manager.
- zincfingers 3y ago
  Spack is a lot more than just python package manager :)
- cowsandmilk 3y ago
  It’s not a python package manager. It is a generalized package manager written in python.
gyrovagueGeist 3y ago
Neat! I had no idea that Spack can be used for cythonize dependencies. I use it to manage my local compiler/CUDA/Trilinos stack but never considered it for non C++ things.
jborean93 3y ago
That's what PyYAML does as well. It uses PEP 518 [1] to specify the dependencies for the build which PyYAML has included Cython [2]. It's just that for previous releases there was no upper bound here so pip and other tools just selected the latest version which was incompatible. In the past PyYAML included the cythonised .c files in the sdist but as of 5.4.0 they went the PEP 518 route and ensures the client will cythonise them if installing from the sdist. [1] - https://peps.python.org/pep-0518/ https://peps.python.org/pep-0518/ [2] - https://github.com/yaml/pyyaml/blob/release/6.0/pyproject.toml#L2 https://github.com/yaml/pyyaml/blob/release/6.0/pyproject.to...
- stabbles 3y ago
  My impression is that the Python ecosystem rarely specifies upperbounds on dependencies even if they follow semver. In the Julia ecosystem it's the default, and you basically have to release a new patch version for updated compat bounds with your dependencies. This is much more stable. It works because the process is mostly automated: dependency releases new version => a bot opens a PR on your repo updating the compat bound, you just merge it.

x3n0ph3n3 3y ago

Oh great, yet _another_ Python package manager.

zincfingers 3y ago
Spack is a lot more than just python package manager :)
cowsandmilk 3y ago
It’s not a python package manager. It is a generalized package manager written in python.

gyrovagueGeist 3y ago

Neat! I had no idea that Spack can be used for cythonize dependencies. I use it to manage my local compiler/CUDA/Trilinos stack but never considered it for non C++ things.

jborean93 3y ago

That's what PyYAML does as well. It uses PEP 518 [1] to specify the dependencies for the build which PyYAML has included Cython [2]. It's just that for previous releases there was no upper bound here so pip and other tools just selected the latest version which was incompatible. In the past PyYAML included the cythonised .c files in the sdist but as of 5.4.0 they went the PEP 518 route and ensures the client will cythonise them if installing from the sdist. [1] - https://peps.python.org/pep-0518/ https://peps.python.org/pep-0518/ [2] - https://github.com/yaml/pyyaml/blob/release/6.0/pyproject.toml#L2 https://github.com/yaml/pyyaml/blob/release/6.0/pyproject.to...

stabbles 3y ago
My impression is that the Python ecosystem rarely specifies upperbounds on dependencies even if they follow semver. In the Julia ecosystem it's the default, and you basically have to release a new patch version for updated compat bounds with your dependencies. This is much more stable. It works because the process is mostly automated: dependency releases new version => a bot opens a PR on your repo updating the compat bound, you just merge it.