-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Add dynamic version from environment variable #3885
base: main
Are you sure you want to change the base?
Add dynamic version from environment variable #3885
Conversation
I like the idea in principle. Is there any prior art? Was it already discussed somewhere? Maybe the documentation should make it clear that the environment variable will be read only when building the sdist but not the wheel. As far as I understood, this is the expected behavior, isn't it? |
I am not sure about this one... Isn't it this a bit of an edge-case1 that we not necessarily need to optimise for? import os, setuptools
setup(version=os.getenv("MY_VERSION_ENV_VAR")) Footnotes
|
Based on my monitoring of StackOverflow, it does come up, not often but quite regularly. I guess there are multiple reasons:
|
An error message will be displayed, but the content can be improved. @abravalheri, I appreciate your input and agree that there may be some workarounds that could be implemented. However, as @sinoroc has pointed out, these are precisely the underlying concerns that prompted me to create this solution in the first place. My goal with this solution is to add a feature that may prevent developers from moving from |
I don't know @IlyaMichlin... Personally I am a bit unease with this FR1. Maybe the best would be asking for the other maintainers if they are OK with that. (@jaraco do you have any thoughts?)
Please note that using
The question in the StackOverflow seems to be a bit more nuanced than simply extracting the version from an environment variable, and I genuinely believe that the best answer for that particular question is complementing It is very unlikely that Footnotes
|
I don't feel strongly either way. On one hand, as abravalheri points out, On the other hand, if there's broad desire for such a feature (more than one org or more than a few individual users), it'd be nice to support it in pyproject.toml and obviate even more use-cases that rely on setup.py. My biggest concern is that the dynamic option is setuptools-specific. If there were just one other build backend considering supporting this feature, I'd feel a lot better about it. I too have wished I could supply/override the version with an environment variable, but that was in situations where the SCM metadata wasn't present, but in that case,
I just read the StackOverflow question and I now agree that this proposed change doesn't even satisfy that user's use-case (having an environment variable override, but defaulting to an attribute). Are there cases that can really benefit from this feature as drafted? Can you point to them? If so and they're numerous, we should consider merging the feature. Otherwise, I'm -1. |
Based on this request from StackOverflow.
Summary of changes
Pull Request Checklist
changelog.d/
.(See documentation for details)