Skip to content

Consider using setuptools-scm #158

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
Closed
c24t opened this issue Sep 20, 2019 · 6 comments
Closed

Consider using setuptools-scm #158

c24t opened this issue Sep 20, 2019 · 6 comments
Assignees
@toumorokoshi
Labels
build & infra Issues related to build & infrastructure. meta Related to repo itself, process, community, ... release:after-ga To be resolved after GA release

Comments

@c24t
Copy link
Member

c24t commented Sep 20, 2019

@a-feld has a slick versioning solution that uses setuptools-scm to set the version from git tags.

We should consider doing the same thing here to avoid updating version files by hand. Note that this doesn't mean that we have to release in response to git tags.

This approach also suggests that we should release all packages in the repo with the same version number on each release, or split these packages into separate. This decision TBD.
@c24t c24t added the meta Related to repo itself, process, community, ... label Sep 20, 2019
@c24t c24t mentioned this issue Sep 30, 2019
Merged
@c24t c24t added this to the Alpha v0.4 milestone Oct 11, 2019
@toumorokoshi toumorokoshi self-assigned this Dec 31, 2019
@toumorokoshi
Copy link
Member

In an effort to start simplifying our development and publishing story, I'll take this one up.

Here's my current proposal:

  1. move all packages to use setuptools_scm (this seems fairly trivial)
  2. migrate as much information from setup.py into setup.cfg as possible (all extensions have setup.cfgs, the api and sdk package do not).
  3. tag a new version 0.4dev0 to ensure that package versions match current expectations.

Alternative to #3 is to up the minor version to 0.5. In general, when moving packaging and versioning schemes this is a good practice, as it avoids potential collisions.

@toumorokoshi
Copy link
Member

unfortunately setuptools-scm is not working well due to it's reliance on information that is only available in the actual source repo: pypa/setuptools-scm#357

@Oberon00
Copy link
Member

Oberon00 commented Jan 7, 2020

I think it is able to cope with the zipped source package too, by generating meta-information into it. The only thing that I can think of that would break is, is copying the source manually without the .git folder. I never tried it myself though.

@toumorokoshi toumorokoshi removed this from the Alpha v0.4 milestone Jan 14, 2020
@toumorokoshi
Copy link
Member

removing from 0.4 as the integration is not as straightforward, and requires changes to setuptools_scm or to our repository hierarchy.

@toumorokoshi
Copy link
Member

looks like pip has changed their behavior! https://github.com/pypa/pip/pull/7882/files. So we may be able to use setuptools_scm now!!

@codeboten codeboten added build & infra Issues related to build & infrastructure. release:after-ga To be resolved after GA release labels Jul 22, 2020
@codeboten
Copy link
Contributor

No plans on doing this in the near future. Closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@toumorokoshi toumorokoshi

Labels
build & infra Issues related to build & infrastructure. meta Related to repo itself, process, community, ... release:after-ga To be resolved after GA release
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@codeboten @toumorokoshi @Oberon00 @c24t