Embed pep-0008 / pep-0396 version number #787
Conversation
|
Out of curiosity, how does this interact with https://gpiozero.readthedocs.io/en/stable/faq.html#how-can-i-tell-what-version-of-gpiozero-i-have-installed ? |
|
Ahhh, I thought I remembered this cropping up before... see #381 |
|
We tend to do it this way in projects now: https://github.com/piwheels/piwheels/blob/master/setup.py#L18 So maybe we should move to that style here. |
No change. You can still use
|
I only moved version information, I wanted to see if there was an appetite for this approach. I don't feel strongly that the other meta data should move (note I've moved most meta data into modules I personally maintain so its all in one place). I do feel strongly that both version string and version tuple should be available, I noticed that in the link above the Python version tuple was made use of :) https://github.com/piwheels/piwheels/blob/master/setup.py#L6 (note this is called behaves sanely, as does: whilst avoiding shenanigans with: which then fail if non-numeric version entries are present. |
|
For reference I looked up the python packaging documentation: It does post the following warning about this technique
|
Yes I found that out on the first round of building for piwheels - many projects failed to run setup.py for this reason! I think it's safe if there's only metadata in your |
|
@waveform80 do you have any thoughts? Should we move to the piwheels way? |
|
I have a feeling this won't work because running |
Precisely - there's a lot of stuff that implicitly happens when gpiozero is imported, which is why I really don't want to do that in setup.py. It is possible to work around this by "parsing" the (Aside: incidentally, I do tend to include the version in this way when building applications (as opposed to libraries) but that's because the root Anyway, I'm afraid I don't see the trade-off of having |
|
We could add Or... could we create, say |
|
I use a little utility called bumpversion that updates the version string in the files I specify. This might be helpful if you go with the above idea: |
Nope, importing any module under gpiozero will implicitly import init.py too - that's just how the importer machinery works (traverses the hierarchy of modules above the one you're importing). For now, this won't work unless we want to incorporate some parsing machinery into setup.py which I'm not terribly keen on. Once we ditch 2.7 support in 2.x, there are actually some ways around this (using some of the built-in parsing facilities in setup.cfg), but for now this'll have to wait. |
|
For newer version this is not required anymore as the >>> import importlib.metadata
>>> importlib.metadata.version("gpiozero")
'1.5.1'
>>> tuple(int(x) for x in importlib.metadata.version("gpiozero").split("."))
(1, 5, 1) |
Sample: