You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the issues of this repo and believe that this is not a duplicate.
I have searched the FAQ and general documentation and believe that my question is not already covered.
Feature Request
Currently, the multi-platform support in Poetry is very limited, e.g. this bug illustrates how hard it is to develop on Linux and Mac using one poetry lock file: #6956.
It's also very hard to develop on multiple Python versions side-by-side (for example, if you want to test a library on multiple versions). You have switch environment, re-update and re-install.
There are also limitations to the lock file: There isn't a good way to create a lock file for a second platform. There isn't a way to create a lock file for a second Python version.
Instead of wrestling with this, how about having a matrix of builds like Travis, where each build lists a platform and Python version. When someone does poetry update, run over all of the builds and calculate a section of the lock file for that build. poetry install would use the appropriate build for the user's platform and Python version.
This would ensure that the uploaded lock file has all of the information for all of the systems. This would solve the cross-platform/cross-version support problems.
Some optimizations would be to have poetry update only update the current system, and have a poetry update all update them all (if possible).
To specify the matrix, you could have a poetry section like
The lock file would contain one section for each element in the matrix, and nothing else. It would be an error to do poetry update with the current system not in the matrix if there is a matrix.
The text was updated successfully, but these errors were encountered:
The poetry lockfile is already intended to be cross platform, so most of what you are saying is based on a misunderstanding:
you don't need to re-update to switch to a new environment (and no solution could remove the "switch environment and re-install" steps)
"there isn't a good way to create a lock file for a second platform" doesn't make sense, it's already a cross-platform lockfile
Your goal to "ensure that the uploaded lock file has all of the information for all of the systems" is already the goal
that's not to say that there aren't issues, of course there are. But I don't think that a significant rewrite of the sort that you are implying here is likely to help
(I also don't see a line of people queueing up to do it! but feel free to prove me wrong with a merge request...)
Fair enough. I guess I misunderstood the poetry internals! However, I did notice that when I switch platform and poetry update, it gives me all different hashes for my packages. So it seems like it's replacing its lock file information rather than stashing the new platform's information in a different section of the lock file.
Feature Request
Currently, the multi-platform support in Poetry is very limited, e.g. this bug illustrates how hard it is to develop on Linux and Mac using one poetry lock file: #6956.
It's also very hard to develop on multiple Python versions side-by-side (for example, if you want to test a library on multiple versions). You have switch environment, re-update and re-install.
There are also limitations to the lock file: There isn't a good way to create a lock file for a second platform. There isn't a way to create a lock file for a second Python version.
Instead of wrestling with this, how about having a matrix of builds like Travis, where each build lists a platform and Python version. When someone does
poetry update
, run over all of the builds and calculate a section of the lock file for that build.poetry install
would use the appropriate build for the user's platform and Python version.This would ensure that the uploaded lock file has all of the information for all of the systems. This would solve the cross-platform/cross-version support problems.
Some optimizations would be to have
poetry update
only update the current system, and have apoetry update all
update them all (if possible).To specify the matrix, you could have a poetry section like
The lock file would contain one section for each element in the matrix, and nothing else. It would be an error to do
poetry update
with the current system not in the matrix if there is a matrix.The text was updated successfully, but these errors were encountered: