Build project with pyproject.toml

[Armavica]

Description

Related Issue

• Closes #
• Related to #

Checklist

• Checked that the pre-commit linting/style checks pass
• Included tests that prove the fix is effective or that the new feature works
• Added necessary documentation (docstrings and/or example notebooks)
• If you are a pro: each commit corresponds to a relevant logical change

Type of change

• New feature / enhancement
• Bug fix
• Documentation
• Maintenance
• Other (please specify):

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.95%. Comparing base (db4020b) to head (12ddac2).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8011   +/-   ##
=======================================
  Coverage   91.95%   91.95%           
=======================================
  Files         128      128           
  Lines       21275    21276    +1     
=======================================
+ Hits        19563    19564    +1     
  Misses       1712     1712           

see 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ricardoV94]

@maresb can you review this and @Armavica can you fix the conflicts. Sorry this slipped through the cracks

[tomicapretto]

To which extent do we want to embrace Pixi here? Bambi's dev workflow is built on top of Pixi and I like how clean it looks like and I think I could help. But I guess here we don't want to force people to have Pixi installed in order to contribute to PyMC?

[maresb]

Sorry, I'm really slammed at the moment, but I have a slightly different approach that I took in PyTensor in pymc-devs/pytensor#1542

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[Armavica]

I'm changing the scope of this PR to ignore the pixi stuff for now and focus on ditching setup.py in favor of the declarative pyproject.toml

[read-the-docs-community]

Documentation build overview

📚 pymc | 🛠️ Build #34988298 | 📁 Comparing 12ddac2 against latest (bf8abd5)

  🔍 Preview build  

367 files changed · ± 367 modified

± Modified

• genindex.html
• glossary.html
• api/math.html
• contributing/jupyter_style.html
• contributing/pr_tutorial.html
• _modules/pymc/math.html
• _modules/pymc/pytensorf.html
• api/distributions/censored.html
• api/distributions/custom.html
• api/distributions/simulator.html
• and 357 more...

[Armavica]

I checked that both the sdist and the wheel contain the same files before and after this change

[ricardoV94]

one more place to update dependencies :)

[Armavica]

One different place rather, because this removes requirements.txt!

[ricardoV94]

I don't see it excluded? nor the -devs one? Happy if they can go

[Armavica]

Damn, sorry, bad rebase. Now it is.
The requirements-devs.txt is another problem because it is auto-generated from the conda env. I think it can be tackled in its own time

[ricardoV94]

seems to only be used for binder... would be nice to get rid of it next yeah

[ricardoV94]

@maresb anything we need to do on pypi or conda side after this?

[maresb]

This is so amazing, great work @Armavica!!! 🤩

This shouldn't require any changes on the conda-forge side apart from updating the setuptools and python constraints.

(BTW, any particular reason to pin python<3.15? Python is so stable that I question if it's actually necessary?)

It looks like versioneer is failing to set the version in the wheel/sdist, falling back to 0.0.0. In order to restore the correct version, I think we still need a mini setup.py with something like the following:

import versioneer
from setuptools import setup

setup(
    version=versioneer.get_version(),
    cmdclass=versioneer.get_cmdclass(),
)

[Armavica]

Thank you @maresb !

(BTW, any particular reason to pin python<3.15? Python is so stable that I question if it's actually necessary?)

I was thinking that if we don't explicitly test it in the CI, it might be wise to pin it?
Anyway I am planning to increment the pin tomorrow when Python 3.15 drops and we can include it in the CI :)

It looks like versioneer is failing to set the version in the wheel/sdist, falling back to 0.0.0. In order to restore the correct version, I think we still need a mini setup.py with something like the following

Ah yes indeed, thank you. I am wondering if it might be worth at some point moving to setuptools-scm, maintained by the PyPA and described as "the blessed package to manage your versions by scm tags"

[maresb]

Looks great now!

Ah yes indeed, thank you. I am wondering if it might be worth at some point moving to setuptools-scm, maintained by the PyPA and described as "the blessed package to manage your versions by scm tags"

Yes, I was thinking the exact same thing! I'd prefer to tackle setuptools-scm in a separate PR because that also changes which files get included in the sdist, and would require a careful audit of the wheel/sdist included files and metadata.

I was thinking that if we don't explicitly test it in the CI, it might be wise to pin it?

My thinking on the matter has changed drastically over the years. If you happen to have a day to spare for reading about version constraints, I find this argument quite compelling, but I wouldn't block this PR on it.

[ricardoV94]

I'm cautiously marking this PR as "major"

[williambdean]

exciting!

[maresb]

@ricardoV94, I think this is safe to tag as "maintenance" since I've validated the sdist and wheel artifacts. But the improvement itself is "major" 😉