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

Move HoloViz projects from setup.py to pyproject.toml #106

Open
maximlt opened this issue Dec 14, 2022 · 3 comments
Open

Move HoloViz projects from setup.py to pyproject.toml #106

maximlt opened this issue Dec 14, 2022 · 3 comments

Comments

@maximlt
Copy link
Contributor

maximlt commented Dec 14, 2022

Having to rely on a declarative file like pyproject.toml instead of on a Python module like setup.py will bring some advantages. It would for instance make it easier to collect the dependencies required by a package and convert them to an environment.yml file. A project like conda-lock has very good support for this file format.

@maximlt maximlt added this to Infra Dec 14, 2022
@jbednar
Copy link
Contributor

jbednar commented Dec 15, 2022

I thought we'd already investigated this and had problems, but it looks like it was for an earlier incarnation of declarative files: holoviz/holoviz#154 . As that issue hints, maybe the toml version eliminates those limitations now that it's in wider use? In HoloViz we do love our declarative approaches, when they actually work! :-)

@maximlt
Copy link
Contributor Author

maximlt commented Dec 19, 2022

Yes indeed things should be better at this point. Yet pyproject.toml isn't fully declarative, in the sense that there are still some fields that can/need to be computed dynamically. This is for instance the case for version, and we'll have to see if param.version works in that case too without any change.

Probably trying to convert Panel from setup.py to pyproject.toml would give us enough insight.

@maximlt
Copy link
Contributor Author

maximlt commented Feb 27, 2023

I had a brief look at this and will list here some difficulties to address:

  • Dynamic versioning support. An update to param.version would be required or we would need to find a replacement. Keeping track of a discussion on this here: autover compared to setuptools_scm autover#47

  • Extras dependencies computed from other sets of extras. The common one is all but there may be others. It looks like the extras can depend on other extras self-referencing the package, e.g. all = ['param[test]', 'param[docs]', 'param[examples]']. Would be nice to find the spec that documents that (navigating the Python packaging docs is not easy).

  • Copying the examples folder in the package tree (e.g. from ./examples to ./hvplot/examples). TBD. Just noting that this is only done when this is true: if 'develop' not in sys.argv and 'egg_info' not in sys.argv.

  • Template the conda recipe with metadata read from pyproject.toml. conda-build can read data from TOML: {% set pyproject = load_file_data('../pyproject.toml', from_recipe_dir=True) %}. It gets trickier with dynamic fields like version. One approach is to compute the version dynamically and inject it with an environment variable. E.g. this is how you'd do it with setuptools_scm:

      VERSION=`python -m setuptools_scm` conda build conda.recipe
    
  • ...

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

No branches or pull requests

2 participants