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.

Sign up for GitHub

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

Jump to bottom

README should mention that PyPI doesn't accept local version identifiers #322

Closed
webknjaz opened this issue Dec 7, 2018 · 4 comments · Fixed by #858 · May be fixed by OlenaYefymenko/setuptools_scm#1
Closed

README should mention that PyPI doesn't accept local version identifiers #322

webknjaz opened this issue Dec 7, 2018 · 4 comments · Fixed by #858 · May be fixed by OlenaYefymenko/setuptools_scm#1
Labels
documentation

Comments

@webknjaz
Copy link
Member

webknjaz commented Dec 7, 2018

And maybe suggest some workarounds for that.

Currently I came up with:

  1. Setting env var with no local identifier 
    python -c 'import setuptools_scm; print(setuptools_scm.get_version(local_scheme=lambda v: ""))' | read SETUPTOOLS_SCM_PRETEND_VERSION
    which is scary because of setuptools_scm should support custom per-project SETUPTOOLS_SCM_PRETEND_VERSION var #321
  2. substituting setuptools_scm.local_scheme entrypoint with lambda v: ""

Which should probably be done only when uploading the dist because in all other cases it's still nice to have local identifier.

Ref: pypa/twine#430
Ref: pypa/packaging.python.org#578
@RonnyPfannschmidt
Copy link
Contributor

it works fine with local pypi servers, and its actually intended to be a protection - don't accidentally upload "non-releases"

for a normal release processs you'd never need the workarounds

@webknjaz
Copy link
Member Author

webknjaz commented Dec 7, 2018

Right. And yet this'd better be documented.
My use case is continuously uploading dists to Test PyPI to ensure that the pipeline is healthy, for example.

@RonnyPfannschmidt
Copy link
Contributor

thats a interesting one, def worthwile

@chebee7i
Copy link

Thanks for this. It would be nice if this could be configurable (not just via env variable).

I use local version identifiers in packages that are uploaded to a local devpi server. Removing the tag is definitely undesirable, as it is used to indicate actual differences in the bdist when building extension libraries (for example, the extension may be built to statically link against different versions of a library).

@webknjaz webknjaz mentioned this issue Jun 8, 2020
Open
OlenaYefymenko added a commit to OlenaYefymenko/setuptools_scm that referenced this issue Apr 28, 2023
@OlenaYefymenko @webknjaz
Emphasize permitted version format for publication
1bc675a 
The patch adds mention in README that local version identifiers don’t allow
publishing to PyPI/TestPyPI. Also, it suggests local private index (devpi)
if required to use the local component in versions.

Resolves pypa#322

Co-authored-by: Sviatoslav Sydorenko <webknjaz+github/profile@redhat.com>
@OlenaYefymenko OlenaYefymenko mentioned this issue May 1, 2023
Open
OlenaYefymenko added a commit to OlenaYefymenko/setuptools_scm that referenced this issue May 7, 2023
@OlenaYefymenko @webknjaz
Emphasize permitted version format in packages for publication
76d1a13 
The patch adds mention in README that local version identifiers in packages
don't allow publishing to PyPI/TestPyPI. Also, it suggests alternative local
servers for using local version identifiers.

Resolves pypa#322

Co-authored-by: Sviatoslav Sydorenko <webknjaz+github/profile@redhat.com>
OlenaYefymenko added a commit to OlenaYefymenko/setuptools_scm that referenced this issue May 28, 2023
@OlenaYefymenko @webknjaz
Emphasize permitted version format in packages for publication
3eb3ce3 
The patch adds mention in README that local version identifiers in packages
don't allow publishing to PyPI/TestPyPI. Also, it suggests alternative local
servers for using local version identifiers.

Resolves pypa#322

Co-authored-by: Sviatoslav Sydorenko <webknjaz+github/profile@redhat.com>
OlenaYefymenko added a commit to OlenaYefymenko/setuptools_scm that referenced this issue May 29, 2023
@OlenaYefymenko @webknjaz
Emphasize permitted version format in packages for publication
dc4879c 
The patch adds mention in README that local version identifiers in packages
don't allow publishing to PyPI/TestPyPI. Also, it suggests alternative local
servers for using local version identifiers.

Resolves pypa#322

Co-authored-by: Sviatoslav Sydorenko <webknjaz+github/profile@redhat.com>
OlenaYefymenko added a commit to OlenaYefymenko/setuptools_scm that referenced this issue May 29, 2023
@OlenaYefymenko @webknjaz
Emphasize permitted version format in packages for publication
6f3bfa6 
The patch adds mention in README that local version identifiers in packages
don't allow publishing to PyPI/TestPyPI. Also, it suggests alternative local
servers for using local version identifiers.

Resolves pypa#322

Co-authored-by: Sviatoslav Sydorenko <webknjaz+github/profile@redhat.com>
@OlenaYefymenko OlenaYefymenko mentioned this issue May 29, 2023
Merged
OlenaYefymenko added a commit to OlenaYefymenko/setuptools_scm that referenced this issue May 29, 2023
@OlenaYefymenko @webknjaz
Emphasize permitted version format in packages for publication
b6c0412 
The patch adds mention in README that local version identifiers in packages
don't allow publishing to PyPI/TestPyPI. Also, it suggests alternative local
servers for using local version identifiers.

Resolves pypa#322

Co-authored-by: Sviatoslav Sydorenko <webknjaz+github/profile@redhat.com>
RonnyPfannschmidt pushed a commit that referenced this issue May 31, 2023
@OlenaYefymenko @webknjaz
Emphasize permitted version format in packages for publication (#858)
dceaeb6 
* Emphasize permitted version format in packages for publication

The patch adds mention in README that local version identifiers in packages
don't allow publishing to PyPI/TestPyPI. Also, it suggests alternative local
servers for using local version identifiers.

Resolves #322

Co-authored-by: Sviatoslav Sydorenko <webknjaz+github/profile@redhat.com>

* Edit typo in README.rst

Co-authored-by: Sviatoslav Sydorenko <wk.cvs.github@sydorenko.org.ua>

---------

Co-authored-by: Sviatoslav Sydorenko <webknjaz+github/profile@redhat.com>
Co-authored-by: Sviatoslav Sydorenko <wk.cvs.github@sydorenko.org.ua>
gmgunter added a commit to gmgunter/snaphu-py that referenced this issue Jan 18, 2024
@gmgunter
Remove local version identifiers
1e9ae24 
By default, setuptools_scm applies "local version identifiers" to
non-tag versions [^1]. In practice, this means appending the short git
hash as a suffix to the version string.

However, TestPyPI doesn't allow publishing distributions that include
local version labels [^2][^3][^4]. This is intended to prevent
accidental upload of non-release versions, but it makes it a bit more
complicated to test our CD pipeline.

We could try to work around this by spoofing the version using
`SETUPTOOLS_SCM_PRETEND_VERSION`[^5]. Alternatively, we could simply
disable local version identifiers in the setuptools_scm configuration.

Including the git hash in the version string of non-tag builds seems
very useful, but handling the version spoofing in CI seems much more
complicated than I'm willing to tolerate.

So for now we'll forego the local version labels, but in the future it'd
be nice to reenable them and adopt a better workaround.

[^1]: https://packaging.python.org/en/latest/specifications/version-specifiers/#local-version-identifiers
[^2]: pypa/setuptools-scm#322
[^3]: pypa/setuptools-scm#455
[^4]: pypa/setuptools-scm#478
[^5]: https://setuptools-scm.readthedocs.io/en/latest/overrides/
gmgunter added a commit to isce-framework/snaphu-py that referenced this issue Jan 18, 2024
@gmgunter
Build wheels & sdists in CI (#27)
7beadd2 
* Build wheels & sdists in CI

Add a CI job that runs on pull requests and pushes to main and executes
the following steps:

* Build wheels for Linux & macOS x86_64, as well as Linux i686 and macOS
  ARM64 using cibuildwheel
* Run the test suite using generated wheels (except for macOS ARM64,
  which is cross-compiled)
* Lint wheels using check-wheel-contents
* Build an sdist and lint it using `twine check`
* Publish wheels & sdist to TestPyPI

* Fix TestPyPI URL

The publisher name & URL must match the project name in pyproject.toml.
I was hoping to name the Python module "snaphu" but name the PyPI
package "snaphu-py", but it looks like that's not possible (at least not
possible with this method of publishing distributions).

https://docs.pypi.org/trusted-publishers/troubleshooting/#upload-errors

* Remove local version identifiers

By default, setuptools_scm applies "local version identifiers" to
non-tag versions [^1]. In practice, this means appending the short git
hash as a suffix to the version string.

However, TestPyPI doesn't allow publishing distributions that include
local version labels [^2][^3][^4]. This is intended to prevent
accidental upload of non-release versions, but it makes it a bit more
complicated to test our CD pipeline.

We could try to work around this by spoofing the version using
`SETUPTOOLS_SCM_PRETEND_VERSION`[^5]. Alternatively, we could simply
disable local version identifiers in the setuptools_scm configuration.

Including the git hash in the version string of non-tag builds seems
very useful, but handling the version spoofing in CI seems much more
complicated than I'm willing to tolerate.

So for now we'll forego the local version labels, but in the future it'd
be nice to reenable them and adopt a better workaround.

[^1]: https://packaging.python.org/en/latest/specifications/version-specifiers/#local-version-identifiers
[^2]: pypa/setuptools-scm#322
[^3]: pypa/setuptools-scm#455
[^4]: pypa/setuptools-scm#478
[^5]: https://setuptools-scm.readthedocs.io/en/latest/overrides/

* Don't build wheels or publish to TestPyPI for PRs

Instead, these CI jobs should only be triggered by pushes to upstream
branches.

Building wheels is very slow compared to the other CI jobs (up to an
hour for 32-bit Linux wheels vs 1-2 minutes for the basic build&test CI
pipeline).

Furthermore, publishing to TestPyPI via OIDC seems to be impossible in
pull requests from public forks. The maximum allowed `id-token`
permissions for public forks is `read` [^1], whereas publishing via OIDC
requires `id-token: write` permissions [^2].

[^1]:
https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
[^2]:
https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#adding-permissions-settings
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
documentation
Projects
None yet
Milestone
No milestone
3 participants
@RonnyPfannschmidt @chebee7i @webknjaz