-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Project metadata #1036
Comments
For the record to do that, you need to ship the *.toml file with your wheels |
That would require to depend on both setuptools (for pkg_resources) and toml (to parse it) – no? |
Toml is not really required for simple key-values: #144 (comment) |
IIRC there were some issues when parsing toml using an ini parser. Regardless, I really don't think that loading and parsing a file in your I'd personally prefer if poetry could actually get its metadata from the |
It's recommended to use I think this should not be handled by poetry, which prefers semantic versioning. A wiki to gather solutions of this kind of puzzles is probably what |
This use case should be covered by from importlib_metadata import version
__version__ = version(__package__) This will use the package data that is persisted in |
The specific question here is
The approach I mention above answers this question, since the I should also mention that |
@chrahunt It is still different from parsing version number from And the path introduces another coupling to |
If we take the question as-stated: "based on the data in pyproject.toml", then I think it is OK to derive it from the metadata which is based on the data in pyproject.toml. Can we think of any use cases that are not covered by using
There is nothing pip-specific here. The mentioned behavior is true for any Python packages as specified in PEP 345 ( |
Just to be clear, I'm not suggesting any change in poetry for this, I think that an approach like I mentioned above (or a better one if we can come up with it) needs to be documented somewhere since it will be a common problem poetry users will have. |
@chrahunt But |
|
I'd like to add my +1 to the original request and my experience with a confusing bug due to this: I have a package with a version = "1.5.0"
include = ["pyproject.toml", "mypackage/**/*.py"] In import pkgutil
import re
version_regexp = re.compile(r'''^version = "([^"]*)"''', re.M)
data = pkgutil.get_data(__package__, "../pyproject.toml")
match = version_regexp.search(data.decode("utf-8"))
if match:
__version__ = match.group(1)
else: # pragma: no cover
raise RuntimeError("Unable to find version string") This seems to work and doesn't depend on a toml package for parsing (at the risk of the regexp failing). When installing this package, my
In addition to:
This works "fine" until I installed another package that is doing the same thing (e.g. It seems like an ideal solution would be some way to use Both this ticket and #890 seem to cover the related functionality to make something like this easier/possible. There is an open PR: #901 -- is there something I can do to help get this merged in (reviews, testing, etc)? |
The override can be avoided by not getting the version number in runtime. I don't know if it is a fasion to get version number like this thread describes but I hate it (without effective verification.) You are exploiting |
In #144 (also linked above) it was mentioned that bumping version in both Something like |
@chrahunt I mean the checksum in metadata in the case of getting version in runtime that you mentioned. By the way, how is it going about your |
From now on version will only be declared in pyproject.toml. Comment on importlib use with poetry: python-poetry/poetry#1036 (comment).
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This is still relevant 🤖 Poetry could get a way to extract metadata from code (like flit and setuptools), call an arbitrary function, or (if it takes that stance) document how to use importlib.metadata to get version. |
The solution given by @chrahunt using |
During `poetry install`, Poetry installs the project as if it were a package itself. You can then pull the version from the package metadata. It's a little tricky to get `importlib_metadata` to work with Docker. You have to remove `--no-root` from the _Dockerfile_ and add `importlib-metadata` to prod dependencies, and you still might get errors after that. python-poetry/poetry#144 python-poetry/poetry#1036
br3ndonland/test3@227ab28 During `poetry install`, Poetry installs the project as if it were a package itself. You can then pull the version from the package metadata. It's a little tricky to get `importlib_metadata` to work with Docker. You have to remove `--no-root` from the _Dockerfile_ and add `importlib-metadata` to prod dependencies, and you still might get errors after that. python-poetry/poetry#144 python-poetry/poetry#1036
So far, testing has been limited to the Python modules. However, the pyproject.toml is an important source of metadata for the project. This commit will use toml (pytest dependency) to load pyproject.toml, and Pydantic (FastAPI dependency) will be used for data validation. Unit tests will verify the presence of select fields in the pyproject.toml. It is also possible to use `importlib.metadata` to read other package metadata, as explained in python-poetry/poetry#1036. The metadata originate in pyproject.toml, and becomes available after Poetry installs the root project package. The `importlib.metadata` approach works in a virtualenv, in which the Poetry root project is installed, but is error prone in Docker, because the root project is usually not installed. Parsing the TOML is a more durable alternative, because it works even if the root project is not installed. The `importlib.metadata` version calculation in `inboard/__init__.py` was not necessary, so it will be removed.
- Relying on importlib as per python-poetry/poetry#1036 (comment)
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Question
Since poetry stores its metadata like version, homepage etc in pyproject.toml, is there a way for project to introspect themselves after being installed?
There is the "standard" of putting meta data into dunders into the main
__init__.py
such that they can be introspected at runtime.My setup.py-based approach is based on parsing those
__init__.py
s but I could live with inverting that relationship, so is there a way to fill__init__.py
data based on the data in pyproject.toml?FWIW, flit seems to at least extract the
__version__
from there.The text was updated successfully, but these errors were encountered: