-
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
remove circular dependency on export plugin #5980
base: main
Are you sure you want to change the base?
Conversation
bf13ed4
to
2133fa7
Compare
I'm courious how this should work. IIRC removing the plugin essentially means removing the export command from the default installation. This is something we really like to do in the future, but for now this would be a breaking change. |
2133fa7
to
671f7cc
Compare
Sure, people who want If we want |
7369814
to
b04265b
Compare
I can see we're going to need consensus here... somehow. While we're thinking about disentangling these two projects, here are some more thoughts. I'd be inclined to transfer the bits of export-specific code that linger in this repository over to the plugin entirely. That is: That would allow deleting the horrid cross-repository github workflow, making it much easier to make fixes to the export function. It would also make it easier to add enhancements if the export plugin was more involved in walking the dependency tree eg python-poetry/poetry-plugin-export#91 would like access to information that is known inside that code. To be clear, I don't intend to do any of that any time soon. But this seems as good a place as any to dump some notes. |
346236b
to
684325d
Compare
Would it be possible to remove the circular dependency but still install the plugin by default? Being able to have Poetry interact with Not having to install a plugin for this kind of functionality (especially since it's a different workflow based on if you are using |
684325d
to
8c7f3be
Compare
aaeb67d
to
d67942a
Compare
Idea: Could the export plugin be an
|
I don't think an extra changes much. We still have a circular dependency (only if the extra is used but nevertheless...). I think a general solution for plugins that are required for a specific project as demanded in #5729 might make more sense. It looks like there is already a POC for project plugins: #5740. Maybe, someone picks this up. |
Okay, wow yes #5729 / #5740 would be a really great way to solve this issue! The specific challenge that this PR will introduce for us is a bootstrapping problem. Whenever we share a Poetry project with another developer, they already need to:
Now we'd need to inform them that they need to:
We've found that these bootstrapping type steps are fraught with developers making small mistakes and thus, we actually avoid Poetry plugins more than we otherwise would because getting them installed everywhere correctly is tricky to document and get everyone to manually install. Hope this feedback is useful! |
9851c40
to
f9911d3
Compare
b1a1bc3
to
2f4a1ff
Compare
2f4a1ff
to
bf60b72
Compare
I'm still in favor of eliminating this circular dependency but I just wanted to point to my comment here: |
0e974c9
to
caa633c
Compare
caa633c
to
c1abbb9
Compare
The circular dependency has been bothering me for a while, but #6441 was the nudge to do something about it.
poetry should not depend on the plugin: the plugin should depend on poetry.
This means that docs that talk about
poetry export
arguably don't belong here at all: but mostly they already say "this is actually provided by poetry-plugin-export" so I've just beefed that up slightly.I'm about to find out what I've broken in the github workflows by removing this dependency...