move export code into export plugin#94
move export code into export plugin#94radoering merged 2 commits intopython-poetry:mainfrom dimbleby:move-code-from-poetry
Conversation
|
In general, I think it's a step into the right direction. The only reason to keep this code in poetry would be that other plugins may use it. However, I don't think this is a likely use case. To my taste, this PR is a bit overloaded. I'd like one PR that just moves the code without any functional adjustments and subsequent PRs that incorporate the fixes. (But that's only my personal opinion. Others might be fine with one PR.) |
|
if y'all would merge the MRs over in poetry, then that's what this would be! |
|
That's "fix bugs first and move code afterwards". That's a bit tricky due to the failing tests. What I proposed is "move code first and fix bugs afterwards". That should work better. I'm just saying that it's easier to review moving the code if there are no functional changes in between. And later the commit history is more comprehensible. |
|
Frankly I got fed up sorting out merge conflicts and rearranging test scripts across the various fixes. Compare the code in this MR to the code in python-poetry/poetry#5711 if you're worried that I might have copy-pasted wrong. Agree that the commit history is slightly less pretty than it might be, but I decided my time was worth more than that - sorry! |
Co-authored-by: David Hotham <[email protected]>
By treating different python version ranges independently, we buy the flexibility needed to make better decisions.
|
Kudos, SonarCloud Quality Gate passed!
|
2 participants
As proposed in python-poetry/poetry#5980 (comment): let's move code that is only used by the export plugin into the export plugin.
I've taken the liberty of rolling up a few fixes that have been stuck, probably because of the difficulty of doing the cross-repository testing. This will close all of:
and it's some sort of step in the right direction for python-poetry/poetry#5980.
I've also removed the dev-dependency on the poetry master branch:
It might be desirable for this plugin to verify that it is in fact compatible with master poetry; but I don't do that here.
Once this is merged and tagged, the corresponding code can be removed from poetry - and IMO at that point it would be sensible for the poetry pipeline to stop running the export-plugin tests.