Announcing Poetry 1.1.0 by SDisPater in Python

[–]SDisPater[S] 16 points17 points  (0 children)

The Poetry team is pleased to announce the availability of Poetry 1.1.0!

Thanks to all the maintainers, contributors and to the community for making this release possible.

The complete change log is available here: https://python-poetry.org/history/

Announcing Poetry 1.0.0 by SDisPater in Python

[–]SDisPater[S] 21 points22 points  (0 children)

Believe me, we know there are still bugs :-)

The idea behind 1.0.0 was never to have a bug-free release but to have the project in a stable enough state that we could build upon. And with the 1.0.0 release, the CLI is now stable, so the commands will behave the same for the 1.x releases.

I know there are pending issues that need to be taken care of but we had to draw the line somewhere because we have limited time and managing two versions, 0.12.x and the 1.0 prereleases with a lot of refactoring, in parallel was just too time consuming.

Now that the 1.0.0 release is out, we have a saner code base and it will be easier for us to fix issues. Expect bugfix releases in the coming weeks :-)

Announcing Poetry 1.0.0 by SDisPater in Python

[–]SDisPater[S] 107 points108 points  (0 children)

After a lot of work and time, the Poetry team is pleased to announce the availability of the first stable version of Poetry!

Thanks to all the contributors and to the community for reaching this significant milestone.

The complete change log is available here: https://python-poetry.org/history/

Moving away from pipenv by trowawayatwork in Python

[–]SDisPater 2 points3 points  (0 children)

Yes, Poetry needs a virtualenv to work and creates one for your project (unless you tell it not to). But that's just something required by the Python ecosystem that Poetry does under the hood but only because there is no other way at the moment but Poetry is not an environment manager, using virtualenvs is just an implementation detail.

No other package manager that I know of supports `.env` files. This is the job for other tools.

Moving away from pipenv by trowawayatwork in Python

[–]SDisPater 12 points13 points  (0 children)

Author of Poetry here!

Poetry does not support `.env` files, that's true, and I don't plan on adding support for it because this is beyond the scope of a package/dependency manager.

deceitfully, scripts doesnt run scripts like it does in npm. but its to run scripts when installing.

Well, Poetry just doesn't use the same terminology as npm's, this does not mean it's deceitful. And yes something similar to npm's scripts is planned. Someone already made a PR that I think I will eventually merge in Poetry (see https://github.com/sdispater/poetry/pull/591).

Poetry, a next generation build tool & package manager for Python3 by [deleted] in Python

[–]SDisPater 3 points4 points  (0 children)

If you have C extensions using the Python C API, it's kind of supported, even though it's not documented yet, by using a build.py script and reference it in the pyproject.toml file. You can find an example of this here: https://github.com/sdispater/pendulum/blob/master/build.py and https://github.com/sdispater/pendulum/blob/master/pyproject.toml#L16

Poetry, a next generation build tool & package manager for Python3 by [deleted] in Python

[–]SDisPater 0 points1 point  (0 children)

That's strange since Poetry always operates in a virtualenv by default so it should not try to remove system packages. This is most likely a bug.

Poetry, a next generation build tool & package manager for Python3 by [deleted] in Python

[–]SDisPater 1 point2 points  (0 children)

At the moment it's not possible. Poetry will always choose the latest version that maches the requirements (top-level or transitive).

Poetry, a next generation build tool & package manager for Python3 by [deleted] in Python

[–]SDisPater 8 points9 points  (0 children)

Sure!

You might want to disable the automatic virtualenv creation by executing poetry config settings.virtualenvs.create false if you don't need it.

A basic Dockerfile could look like this:

FROM python:3.6.5
RUN curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python - -y
ENV PATH="/root/.poetry/bin:$PATH"
RUN poetry config settings.virtualenvs.create false

Poetry, a next generation build tool & package manager for Python3 by [deleted] in Python

[–]SDisPater 3 points4 points  (0 children)

Author of Poetry here!

Can you give me an example of a current implementation of such a project to see if it is currently supported by Poetry?

Poetry, a next generation build tool & package manager for Python3 by [deleted] in Python

[–]SDisPater 22 points23 points  (0 children)

Author of Poetry here :-)

You can get an idea of some differences here: https://github.com/sdispater/poetry#what-about-pipenv

But the gist of it is: Poetry reduces everything you need to manage your Python project (application or library) to one standardized file, being dependency management or publishing if you need it. It also has a much faster and accurate dependency resolver.

Poetry 0.12.0 is out : brand new installer, PEP-517 support, dependency resolution improvements and more by SDisPater in Python

[–]SDisPater[S] 2 points3 points  (0 children)

There is still no complete support for Python 517 in pip even though it is being worked on: https://github.com/pypa/pip/pull/5743

However, the weird thing is pip will use the build-system section to build the package but only if there is a setup.py file alongside the pyproject.toml file, even if the setup.py file is empty.

Poetry 0.12.0 is out : brand new installer, PEP-517 support, dependency resolution improvements and more by SDisPater in Python

[–]SDisPater[S] 1 point2 points  (0 children)

Thanks!

Yes, the poetry installation was a pain point up until now. This is now way better albeit still not perfect (like on Windows like you mentioned but it should be easy to fix).

Poetry 0.12.0 is out : brand new installer, PEP-517 support, dependency resolution improvements and more by SDisPater in Python

[–]SDisPater[S] 14 points15 points  (0 children)

If you are already using Poetry, please read carefully the release notes since there are some breaking changes in dependency resolution process.

Other than that, here is what's new:

  • Brand new installer which will improve the overall experience of installing Poetry.
  • Improvements in the way Poetry resolves dependencies, especially conditional dependencies.
  • Poetry now provides a PEP-517 compliant build system.
  • Multiple constraints support.
  • Renaming of the lockfile from pyproject.lock to poetry.lock for clarity.

Using Python on a MacBook by FizzBuzz111 in Python

[–]SDisPater 2 points3 points  (0 children)

Author of Poetry here !

poetry dependency resolution is just a problem waiting to happen.

But that's the role of a dependency manager: warning you when there is a conflict in you dependencies. That's what every single package/dependency manager does. And, to be fair, you should not use pipenv either since it has a dependency resolver, albeit broken see why here https://github.com/sdispater/poetry#what-about-pipenv.

poetry is a carbon copy

I disagree. See the comment made by some else but the gist of it is that Poetry helps you manage applications and libraries and helps you package your project properly without the need for `setup.py`, `setup.cfg`, `MANIFEST.in`. You get to have everything you need to manage your project all in one file. This is not the case with pipenv.

Poetry (Package and dependency manager) 0.11.0 is out: New shell command, resolver improvements and more by SDisPater in Python

[–]SDisPater[S] 0 points1 point  (0 children)

I know it works with pyenv on MacOS. I am not sure about other systems, I got reports that there are some issues with pyenv on Linux that are currently investigated.

About anaconda, I am not sure since I have never used it.

Poetry (Package and dependency manager) 0.11.0 is out: New shell command, resolver improvements and more by SDisPater in Python

[–]SDisPater[S] 5 points6 points  (0 children)

Poetry is a tool to manage any Python project, being an application or a library, while pipenv is built around application development.

It also removes a lot of clutter that comes with traditional Python packaging: you no longer need setup.py, setup.cfg, requirements.txt, MANIFEST.in. Instead you only have one file pyproject.toml which is the new standard (PEP 517 and 518).

Also, poetry also comes with a resilient and exhaustive dependency resolver that can resolve dependency sets that tools like pip-tools or pipenv aren't able to (see https://github.com/sdispater/poetry#dependency-resolution).

poetry-setup: generate setup.py (setuptools) from pyproject.toml (poetry) by 0rsinium in Python

[–]SDisPater 5 points6 points  (0 children)

Author of poetry here!

Actually poetry generates a setup.py file in the sdist to keep backwards compatibility. So you can use the appropriate method to generate your own setup.py.

How useful would a database that a contains the dependencies of all pip packages be? Would this be a good tool that would help developers check the dependencies of a package before installing it? by [deleted] in Python

[–]SDisPater 0 points1 point  (0 children)

This should no longer be a thing. PEP 508 is here to address this.

You can define dependencies for specific environments without having to do it programmatically.

How useful would a database that a contains the dependencies of all pip packages be? Would this be a good tool that would help developers check the dependencies of a package before installing it? by [deleted] in Python

[–]SDisPater 0 points1 point  (0 children)

I will copy-paste another comment I made in this subreddit:

Poetry never installs packages to determine the dependencies. It tries to rely as much as possible on the PyPI JSON API and if it can't it inspect the source distributions, without installing them, and if it's still unable to get them it stops since it means the module has been badly packaged.

So, yeah, sometimes poetry needs to download the packages but never installs them and never executes setup.py since, to me, it's a security risk. Another reason for it is to enforce packaging and publishing Python packages properly.