Feature roadmap

[sdispater]

This is the official feature roadmap for Poetry. This gives an overview of future features and ideas that will be implemented in Poetry and in which release they will be available.

Each feature release will have its own Github project to track the progress being made on these new features

This roadmap is subject to change and features will be added as needed.

1.1

• Lightweight core library (Lightweight core library #1993).
• First phase of improving the packages installation speed : Download distributions separately before installing them (New and faster installer implementation #2595).
• Opt-in option to disable the generation of the setup.py file.
• Drop Python 3.4 support. Note that Poetry will still be able to manage Python 3.4 environments.
• Python 2.7 and 3.5 deprecation (Python 2.7 and 3.5 deprecation #2683).

1.2

• Plugin system ([Discussion] Poetry to provide a decent hook-based plugin system #693, WIP - Plugin system #1237).
• Implementation of a bundle command, see Feature Request: poetry deploy #537 for more context. This command should be pluggable via the plugin system (Bundle command #1992, Bundle command implementation #2682).
• Improve dependency resolution. Better support for system specific wheels and speed improvements.
• Development of a package registry to speed up dependency resolution of packages with missing metadata.
• Second phase of improving the packages installation speed: Implementation of a separate library to replace calls to pip for installation. This will be an opt-in feature in this release.
• Add support for dependency groups (Support dependencies groups #1644).
• Drop Python 2.7 and 3.5 support.

1.3

• Third phase of improving the package installation speed : Make the phase 2 feature the default one with the possibility to opt out.

1.4

• Fourth phase of improving the package installation speed : Disable the possibility to opt out of the phase 2 feature as it should be stable by now.

2.0

[sdispater]

Thanks for your interest in Poetry and for your feedback.

However, this issue is not the place to make feature requests but is reserved for discussion about the current roadmap detailed above. If you want to make a feature request, please open a proper issue with the appropriate template.

That being said there is no plan to add support for conda at the moment.

[seansfkelley]

Is something along the lines of "refine the CLI's UX" suitable for the roadmap? Most of the internals of Poetry I'm quite happy with (well, except for the speed issues already covered), but I find myself cobbling together workflows from commands that aren't quite what I need, but can be abused to make it so.

[jtratner]

Small note: Python 3.4 is already EOL as of March 2019, so if it's causing you trouble, seems reasonable to drop support for it - see Python announcement here - https://www.python.org/downloads/release/python-3410/

[sdispater]

@jtratner Yes, we will drop support for Python 3.4 in the next feature release without going through a deprecation plan.

This decision was taken because, as mentioned above, it was cumbersome and it seems that people have already moved on to more recent versions (see https://pypistats.org/packages/poetry)

I'll update the roadmap to reflect that.

[pietrodn]

A prioritary issue to be included in the next releases is to fix the hash checking of dependencies, IMHO.
See: #2422 (comment)

[pietrodn]

Would it be possible to cut a patch release to include the fix for #2422, which is a security issue? 🙏

[adriangb]

Would it be possible to move the roadmap to a quarterly roadmap and the implement a consistent release cadence? It's kind of a shame that some implemented, working features are only available in pre releases (presumably because they're waiting on other features that are supposed to be included in the same minor release)

[thedrow]

I think we can check #1644 as done.

On another note, could we please release this feature and re-plan the roadmap? This one is really useful and I'd like to be able to use it.

[thedrow]

If there's a need, I'm willing to cut 1.2 myself and release it to the public.
Having dependency groups will improve the workflow for all our users.

[s0undt3ch]

👍 for a release with dependency groups.

[finswimmer]

If there's a need, I'm willing to cut 1.2 myself and release it to the public.

How would this be different from the current alpha release?

[thedrow]

It would allow us to use this feature in production in conjunction with nox-poetry for example. Pre-versions are usually not allowed in production packages.

The feature itself is functional and nothing is preventing its release.
I'd like to be able to install this version without --pre or without working around dependency issues for packages which depend on poetry.

[jakeberesford-palmetto]

Releasing 1.2 with groups ahead of other features slated for 1.2 would help my team hugely, we would prefer not to use a pre-release in production.

[emekdahl-palmetto]

Bump! We need 1.2 with groups!!

[adriangb]

How would this be different from the current alpha release?

I've encountered bugs/issues that have been fixed since the last pre-release that forced me to abandon the pre-release and hop onto the last stable. Granted, this could be fixed with a new pre-release, but that hasn't happened in a while, which discourages me from using any pre-release.

[mitom]

It would be very good to get a clear answer to the prompt for an early 1.2 release specifically for the groups feature (even if the answer is no). Currently, I am stuck in a limbo as this feature would be one of very few things that I need from a dependency manager, and knowing if it has a chance to land in weeks or potentially several months would be a key part in deciding whether we stick with poetry or not.

On a more practical side, it looks like the groups feature is one of 3 non-transparent changes planned for 1.2 (correct me if I misinterpret it, these changes being plugins, groups, bundle command) and the rest are speed improvements. With an external eye, we could have the groups functionality without the rest, so why not?

A 3rd note - if we could have a pre-release with just the groups - assuming that will avoid the issues mentioned above with pre-releases, it could solve this need for at least a portion of us (even though I understand not all of us). Would this be an option?

[haf]

Ref #5459

[dpompeu-xgeeks]

I'd appreaciate an earlier 1.2 release too!

As reproduced in #5743 , I have projects which are applications and others which are internal libraries. If I'm changing something in the libraries, I like to temporarily swap the dependencies to {files = /path/to/local/lib", develop=true} and debug them, but this has strange behaviors in poetry 1.1.13. The changes are not applied when installing and requires workarounds such as removing the virtual env before installing the modified dependency.

I tried version 1.2.0b2.dev0 and it worked much better on it!

[Dilski]

Would love to know timelines for a 1.2 release. Plugins (specifically the bundling plugin) is important for my use case

[g-as]

Would love to know timelines for a 1.2 release. Plugins (specifically the bundling plugin) is important for my use case

See #5586

[opserx]

I think peotry is perfect except for the speed of package installation(or update). Why not focus on fixing speed in a minor version? Of course, I can't thank you enough for your contributions and respect your roadmap.

[neersighted]

Closing this for now as we don't have a definite roadmap -- but this is long out of date and https://github.com/python-poetry/roadmap is the current (also dusty) location of our planning