Poetry 1.2.0

[drhagen]

Comment:

Poetry has released 1.2.0rc2 and is going to finalize 1.2.0 soon. Can I request a cut of the latest release candidate so that I can test how downstream conda dependencies work under 1.2?

[xylar]

We've been having real trouble with circular dependencies between poetry and poetry-plugin-export: python-poetry/poetry#5980

Since that issue is still open, I had assumed that wasn't resolved. conda really cannot handle circular dependencies at all so I don't think we have a workaround for this.

[xylar]

I'll go through the process, though, and see what we find with the latest RCs.

• poetry-core 1.1.0rc3: [DEV] Update to v1.1.0rc3 poetry-core-feedstock#30
• poetry 1.2.0rc2: [DEV] update to v1.2.0rc2 #71

[xylar]

I'm building 1.2.0rc2 but also with a patch from python-poetry/poetry#5980. That's our only way forward here.

[drhagen]

I'm building 1.2.0rc2 but also with a patch from python-poetry/poetry#5980. That's our only way forward here.

I support this. I would rather a release of Poetry 1.2 with the deprecated export function removed than no Poetry 1.2 at all.

[maresb]

This seems fairly dangerous to me. Do we really want a conda-forge version of Poetry which diverges from the standard one? How confident are we that leaving out the export plugin dependency won't lead to ImportErrors?

[maresb]

If the Poetry devs believe this is too big of a change and not suitable for 1.2, shouldn't we listen to them?

[xylar]

So I think the bigger problem is if we simply can't build a package for poetry >=1.2.0 at all. At least this is a way forward. My understanding. But it seems like downsteam users need both poetry and poetry-plugin-export so breaking them into 2 packages was probably not a good move. That's what I'm gathering from the discussion in any case.

[maresb]

Ya, this seems like a pretty terrible situation.

Another horrible but potentially safer hack would be to make a special copy of poetry-plugin-export which doesn't depend on Poetry. Perhaps poetry-plugin-export-deprecated? And then you make poetry depend on that until poetry straightens things out.

[xylar]

I could see how that would "work" better downstream in that installing poetry would get the poetry-plugin-export features. But it's a pretty giant mess.

[maresb]

On a compleeeetely unrelated side note, I must report that I'm very pleased so far with Hatch. 😄

[xylar]

Not something I've tried.

[drhagen]

But it seems like downsteam users need both poetry and poetry-plugin-export so breaking them into 2 packages was probably not a good move.

Breaking functionality out into an optional package is pretty common and normal. The original sin was pulling out the functionality before being truly ready to make the functionality optional.

[xylar]

@drhagen, thanks for the insight. I'm not particularly expert in the specific of poetry or its history.

[xylar]

But I agree, breaking out packages that are optional dependencies (or shared ones) is very handy indeed!

[maresb]

And that happens to be exactly Hatch's philosophy. Standards-based and highly extensible. It even supports Conda environments, though I haven't played with that plugin yet.

[xylar]

As I commented on #72, another problem keeping us from releasing is that there hasn't been a release of cleo 1.0.0.

[maresb]

Haha, hi @ofek! Wasn't expecting to see you here with the 👍. (He's the Hatch maintainer, and is very responsive.)

[mbargull]

I've added a suggestion for a workaround for the current dependency cycle at conda-forge/poetry-plugin-export-feedstock#8 (comment) .

[xylar]

It seems poetry is not yet compatible with cleo 2.0.0, which was just released. We need to keep an eye on python-poetry/poetry#7070 and wait for a new release (or patch?).

[maresb]

While we skipped v1.2, we now have a v1.3 release.