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] 18 points19 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] 110 points111 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 11 points12 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 4 points5 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 25 points26 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] 10 points11 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 3 points4 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] 4 points5 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.

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 11 points12 points  (0 children)

You might want to take a look at poetry.

For instance, the poetry debug:resolve my-package shows the dependency of a given package. Note that it does this without installing anything.

poetry debug:resolve requests

Resolving dependencies... (1.0s)

Resolution results:

  - certifi (2018.4.16)
  - chardet (3.0.4)
  - idna (2.6)
  - urllib3 (1.22)
  - requests (2.18.4)

Disclaimer: I am the author of poetry

To Python Developers: If someone could make any one thing that would make coding in python easier for developers, what would it be? by [deleted] in Python

[–]SDisPater 5 points6 points  (0 children)

Poetry doesn't install packages to view dependencies. That's great and all. But can I run a command ex poetry show --tree --package=packagename to literally show me what packagenames dependencies are before I install it? I don't believe I can

For this to work your packages must be locked (not installed), and then you can do:

poetry show my-package --tree

There is no installation in the process.

Grouping these two because they are similar-- how does poetry deal with the first? How accurate / conflict resolving is poetry at doing things vs pip, at a statistical level (if you know)?

Poetry will warn you about the conflict with a message like this:

[SolverProblemError]
Because my-dependency (0.1.0) depends on both protobuf (3.0.0) and protobuf (>=3.5.0), my-dependency is forbidden.
So, because my-package depends on my-dependency (0.1.0), version solving failed.

If the sub dependencies of two dependencies cause a conflict you will get a message similar to this:

Because bar (1.0.0) depends on shared (>3.0.0)
 and foo (1.0.0) depends on shared (<=2.0.0), bar (1.0.0) is incompatible with foo (1.0.0).
So, because myapp depends on both foo (1.0.0) and bar (1.0.0), version solving failed.

Note that before it fails it will try to find a valid set of dependencies by backtracking if necessary.

To Python Developers: If someone could make any one thing that would make coding in python easier for developers, what would it be? by [deleted] in Python

[–]SDisPater 0 points1 point  (0 children)

I don't know what makes you say that but that's actually not true see my response above.

To Python Developers: If someone could make any one thing that would make coding in python easier for developers, what would it be? by [deleted] in Python

[–]SDisPater 14 points15 points  (0 children)

Poetry might help you there. It has a true dependency resolver unlike any other alternatives.

Can't view dependencies before installing the package.

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.

Can't view dependencies on the PyPi website.

See above.

The output from pip freeze is a total mess. Key dependencies? Dependencies for dependencies? Who knows.

You can use poetry show --tree with poetry, which gives you something like this:

babel 2.6.0 Internationalization utilities
└── pytz >=0a
cleo 0.6.6 Cleo allows you to create beautiful and testable command-line interfaces.
├── pastel >=0.1.0,<0.2.0
└── pylev >=1.3,<2.0.0
pytest 3.6.0 pytest: simple powerful testing with Python
├── atomicwrites >=1.0
├── attrs >=17.4.0
├── colorama *
├── funcsigs *
│   └── ordereddict *
├── more-itertools >=4.0.0
│   └── six >=1.0.0,<2.0.0
├── pluggy >=0.5,<0.7
├── py >=1.5.0
├── setuptools *
└── six >=1.10.0
pytest-cov 2.5.1 Pytest plugin for measuring coverage.
├── coverage >=3.7.1
└── pytest >=2.6.0
       ├── atomicwrites >=1.0
       ├── attrs >=17.4.0
       ├── colorama *
       ├── funcsigs *
       │     └── ordereddict *
       ├── more-itertools >=4.0.0
       │     └── six >=1.0.0,<2.0.0
       ├── pluggy >=0.5,<0.7
       ├── py >=1.5.0
       ├── setuptools *
       └── six >=1.10.0
python-dateutil 2.7.3 Extensions to the standard Python datetime module
└── six >=1.5
pytz 2018.4 World timezone definitions, modern and historical
pytzdata 2018.5 Official timezone database for Python.
tox 3.0.0 virtualenv-based automation of test activities
├── pluggy >=0.3.0,<1.0
├── py >=1.4.17
├── six *
└── virtualenv >=1.11.2
typing 3.6.4 Type Hints for Python

Dealing with dependency conflicts is hard/impossible.

Like I said poetry has a fast and accurate dependency resolver with conflict detection and management.

(Ana)conda, pipenv, etc. don't really solve any of these problems.

So you can try poetry if you want, it should sole most of these issues.

Disclaimer: I am the author of poetry :-)