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

Retrieve project version via setuptools_scm #4774

Open
2 tasks done
Tracked by #12462
wvreeven opened this issue Feb 15, 2023 · 5 comments
Open
2 tasks done
Tracked by #12462

Retrieve project version via setuptools_scm #4774

wvreeven opened this issue Feb 15, 2023 · 5 comments
Labels
source::community catch-all for issues filed by community members type::feature request for a new feature or capability

Comments

@wvreeven
Copy link

wvreeven commented Feb 15, 2023

Checklist

  • I added a descriptive title
  • I searched open requests and couldn't find a duplicate

What is the idea?

As is the case with the load_setup_py_data, the function load_file_data should be able to retrieve the version of the project via setuptools_scm.

Why is this needed?

In pyproject.toml we rely on setuptools_scm to retrieve the version of the project. I have tried to use the new load_file_data function to load our project.toml file but Jinja doesn't retrieve the version via that file. We have followed the instructions here and here to set up project.toml but whatever I try, load_file_data returns the literal string as defined in pyproject.toml and doesn't call setuptools_scm to get the project version.

What should happen?

It should be possible to use the directive {% set data= load_file_data() %} to retrieve the dynamically determined project version via setuptools_scm.

Additional Context

No response

@wvreeven wvreeven added the type::feature request for a new feature or capability label Feb 15, 2023
@beeankha beeankha added the source::community catch-all for issues filed by community members label Feb 15, 2023
@dholth
Copy link
Contributor

dholth commented Feb 16, 2023

Some recipes use version: {{ GIT_DESCRIBE_TAG }}+{{ GIT_BUILD_STR }} in meta.yaml; does this work for your projects? This PR shows a regex-match version that the submitter wants to replace with GIT_DESCRIBE_TAG https://github.com/conda/conda-package-handling/pull/175/files#diff-0286c1d624d881984aef773a82433d955692c2fcbc773e7a6230fdb9602a23a3L1

@beeankha beeankha added the pending::feedback indicates we are waiting on feedback from the user label Feb 16, 2023
@wvreeven
Copy link
Author

Thanks for the suggestion. It turns out that those GIT variables give a different version than setuptools_scm. Using the GIT variables in one of my projects, I get v0.5.0+100_g32547c3 while setuptools_scm gives 0.5.1.dev100+g32547c3.d20230216. It is the latter version that we use with all our projects.

@conda-bot conda-bot added pending::support indicates user is waiting on support from triage engineers and removed pending::feedback indicates we are waiting on feedback from the user labels Feb 16, 2023
@travishathaway travishathaway removed the pending::support indicates user is waiting on support from triage engineers label May 8, 2023
@tomrutter
Copy link

Would it work to allow conda build to pick up version information from the wheel or installed package after the build.sh scripts have run pip install?

@wvreeven
Copy link
Author

wvreeven commented Jul 10, 2023

We don't use build.sh scripts nor do we run pip install. Having said that, why would that be a solution for this? Doesn't the current conda code that gets the version from setup.py do this before the wheel is created or the package installed? Our pyproject.toml creates a version.py file containing the version and this needs to be part of the conda package.

@wvreeven
Copy link
Author

wvreeven commented Sep 4, 2023

Is there any update for this request?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
source::community catch-all for issues filed by community members type::feature request for a new feature or capability
Projects
Status: 🆕 New
Development

No branches or pull requests

6 participants