Official plugin system

[fredrikaverpil]

Hey, have you seen this? 😊
python-poetry/poetry#3733

[mtkennerly]

I did! It's pretty exciting :D Looking forward to updating this to take advantage of it.

[fredrikaverpil]

Looks like it's been merged to master! 😃

[mtkennerly]

I just released v1.0.0b1 using the official plugin interface. I'd appreciate feedback from anyone who wants to try it out. It requires Poetry 1.2.0a2+ and Python 3.6+.

The one issue I know right now is that the plugin behavior doesn't trigger for dependencies, only for the main project. I still need to research how to implement that.

Updated documentation: https://github.com/mtkennerly/poetry-dynamic-versioning/blob/release/v1.0.0/README.md

[fredrikaverpil]

@mtkennerly that's awesome news! 🍾 🎉
I'm (somewhat unfortunately) not using this project anymore, as I've moved on to another company. I therefore have nothing to test this with at the moment.

[mtkennerly]

No worries! Thanks for all the feedback you gave me while you were still using it :)

[Darsstar]

After probably an hour after first contact: so far no issues!

[layday]

Will v1 be usable without Poetry (i.e. with poetry-core only)? My understanding is that Poetry plug-ins are not implemented in the backend, meaning that building a package with dynamic versioning would require installing all of the Poetry CLI's dependencies.

[Darsstar]

The one issue I know right now is that the plugin behavior doesn't trigger for dependencies, only for the main project. I still need to research how to implement that.

Could that be because of pypa/pip#11022?

[mtkennerly]

Will v1 be usable without Poetry (i.e. with poetry-core only)? My understand is that Poetry plug-ins are not implemented in the backend, meaning that building a package with dynamic versioning would require installing all of the Poetry CLI's dependencies.

Right, the official plugin system means it will depend on Poetry itself, not just poetry-core. I'll probably end up releasing a slimmed down version of the existing implementation as poetry-core-dynamic-versioning for that use case. (Edit: On second thought, if there will be two separate packages, it's probably better for the Poetry 1.2+ plugin to get a new name, to avoid breaking packages that have build-system = ["poetry-core", "poetry-dynamic-versioning"] declarations without version constraints.)

Could that be because of pypa/pip#11022?

I think it's just that the Poetry plugin behavior is designed to only affect the active project. I found a workaround, and although it still relies on monkey patching, at least it doesn't need to do import shenanigans with a pth file.

[mtkennerly]

The one issue I know right now is that the plugin behavior doesn't trigger for dependencies, only for the main project. I still need to research how to implement that.

This is now fixed in v1.0.0b3.

[mtkennerly]

As mentioned in #39 (comment), I'm now releasing two separate packages:

• poetry-dynamic-versioning (using the import hack) - just published v0.15.0
• poetry-dynamic-versioning-plugin (using the official plugin system) - just published v0.1.0

I'd only recommend having one installed at a time, but they do attempt to play nice with each other. These new releases are just to reflect the unified code base, so pdv v0.14.1 and v0.15.0 should behave the same as each other, and so should pdv v1.0.0b3 and pdv-plugin v0.1.0.

[mtkennerly]

I think the new poetry-dynamic-versioning-plugin is in a good state, so I'm going to go ahead and close this. I'll keep monitoring Poetry 1.2.x (pre-)releases for any changes that may be necessary.