-
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
poetry build ignores locked versions #1307
Comments
From https://poetry.eustace.io/docs/libraries/#lock-file:
I interpreted that as "the lock file only affects installs done from the project itself, as opposed to from built artifacts", which I think is what you're seeing. |
I think you are interpreting the doc a bit too liberally. It talks about that the output of poetry takes the lock file into account but you should not depend on other tools taking the lock file into account when including your project. Which is perfectly fine. This question/feature request is not related the quoted documentation. I am not asking about nesting my project into another one. I would like the lock file to have an effect on the sdist/wheel build artefacts |
Although since then I realised that the wheel metadata only contains the direct dependencies and not transitive dependencies, unlike the lock file which has every transitive dependency. I still feel a tighter locking of version numbers should be possible in the wheel metadata, I would love to hear some feedback on this from the developers of the tool. |
@ijanos can that not be achieved by just including tighter restrictions on the versions listed in the pyproject.toml? E.g., if you want to pin the version of a transitive dependency, just list it in the pyproject.toml with a pinned version? I think what you are describing might conflict with PEP 518 in some way if it used information outside the pyproject.toml to generate the wheel metadata. (I haven't read it very closely though.) I'm not sure if there is a way to generate a modified pyproject.toml with the locked requirements (similar to the preview version's ability to export Beyond that, it sounds like what you are interested in is something akin to building a wheel with "static linking" to dependencies (i.e., different packages could depend on different versions of the same dependency in the same environment), but I'm not sure whether this is even theoretically possible in python (currently). (Maybe someone more knowledgeable can shed some light..) If you want to distribute sub-projects as wheels without heavy pinning restrictions on the execution environment (so they can be more easily reused), perhaps a better option for any project in which you want to include dependency wheels and still have tight version pinning would be to make use of a poetry "wrapper" project. This project would include all dependencies in its |
Echoing what @dmontagu says, There are libraries and applications. A wheel is intended to distribute a library, which generally supports a range of versions for its dependencies. If each library specified strict version dependencies then it would be very hard for two libraries to coexist. Its generally considered bad practice to have tight dependencies for libraries. For applications (which use a libraries as dependencies) its best practice to lock down the dependencies and sub-dependencies so that your application works exactly as expected. This is what lock files are for. Applications are not distributed via wheels. Docker images are a widely used mechanism for distributing applications. You may also have interest in cutting edge things like PyOxidizer. If for whatever reason you still want really tight dependencies in your wheel then yes you can manually specify them all in your |
Yeah, I see. I am using a wheel to deploy an application basically like this:
I am quite fond of this workflow, my only nitpick is the tighter control over versions but as you suggested I think I will move to tighter specs in the the Can you back up your claim of wheels are intended for libraries? I was not aware of such distinction and I did look at the PEP but found no such intention it has the following defition:
|
Sorry to be necromancing this issue a year later, but this is simply not the case. If wheels weren't intended for distributing apps, console-script entry points wouldn't exist (or at least, would not be so ubiquitous). You might personally prefer to distribute your application as a Docker image rather than a wheel, but not everyone can or should conform to that opinion. A wheel is a perfectly valid distribution for hundreds of applications on PyPI - often it simply involves the user making a virtualenv, running In this use case, it is more suitable for the application's wheel to have all its primary and transitive dependencies pinned to known working versions. An amazing feature for Poetry which would allow its swift adoption as a dependency management tool for applications would be:
Perhaps it should also/instead be a key in the |
Having the option would be really good. |
Having "*" in pyproject.toml for dunamai leads to installation of the latest version after running `poetry build`. And in case of new dunamai release the new version will be installed which can break everything. Related issue: python-poetry/poetry#1307
Having "*" in pyproject.toml for dunamai leads to installation of the latest version after running `poetry build`. And in case of new dunamai release the new version will be installed which can break everything. Related issue: python-poetry/poetry#1307
+1 to what @Tobotimus said. This sort of workflow goes hand in hand with tools like |
+1 to @Tobotimus proposal. |
new issue about this is #2778 |
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. |
Feature Request ?
When running
poetry build
the wheel metadata seems to be generated based on thepyproject.toml
instead of the lock file. Is this intentional? Maybe I am missing something but I thought callingpoetry build
will create a wheel that will install the exact same dependencies from the lock file.here's what the dependencies look like:
And here is the relevant part of the METADATA file from the generated wheel. I expected these to be
==
exact versions.The text was updated successfully, but these errors were encountered: