Versioning - Githubissues

conda-forge / pypy3.6-feedstock

A conda-smithy repository for pypy3.6.

BSD 3-Clause "New" or "Revised" License

4 stars 13 forks source link

Versioning #53

Closed mattip closed 3 years ago

mattip commented 3 years ago

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Fixes #52 by changing the regex for platform._sys_version(). Also fix parsing the hg tag so that sys._mercurial returns the lastest tag, not the earliest (this patch will be part of the next PyPy release)

Also add a test that platform._sys_version() does not crash

conda-forge-linter commented 3 years ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

mattip commented 3 years ago

the new test is printing

('PyPy', '3.7.10', 'release-pypy3.7-v7.3.5', '77787b8f', '77787b8f', 'Jul 29 2021', 'MSC v.1916 64 bit (AMD64)')

mattip commented 3 years ago

@isuruf should we try again to get this in?

tkelman commented 3 years ago

Do you think these should go upstream?

mattip commented 3 years ago

There are two patches here. The tag one (making sure the first tag is taken from the .hg_archival.txt) patches/pre-7.3.6-0010.patch has been upstreamed. The other one (adjusting platform._sys_version for conda-forge-specific sys.version string) is specific to conda-forge and should not be upstreamed to PyPy.

tkelman commented 3 years ago

You don't think the regex should be made to populate compiler, and have the revision be a consistent length with cpython, outside of conda-forge?