Python dependency management and packaging made easy.

Overview

Poetry: Dependency Management for Python

Poetry helps you declare, manage and install dependencies of Python projects, ensuring you have the right stack everywhere.

Poetry Install

It supports Python 2.7 and 3.5+.

Note: Python 2.7 and 3.5 will no longer be supported in the next feature release (1.2). You should consider updating your Python version to a supported one.

Tests Status

The complete documentation is available on the official website.

Installation

Poetry provides a custom installer that will install poetry isolated from the rest of your system by vendorizing its dependencies. This is the recommended way of installing poetry.

curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python

Alternatively, you can download the get-poetry.py file and execute it separately.

The setup script must be able to find one of following executables in your shell's path environment:

  • python (which can be a py3 or py2 interpreter)
  • python3
  • py.exe -3 (Windows)
  • py.exe -2 (Windows)

If you want to install prerelease versions, you can do so by passing --preview to get-poetry.py:

python get-poetry.py --preview

Similarly, if you want to install a specific version, you can use --version:

python get-poetry.py --version 0.7.0

Using pip to install poetry is also possible.

pip install --user poetry

Be aware, however, that it will also install poetry's dependencies which might cause conflicts.

Updating poetry

Updating poetry to the latest stable version is as simple as calling the self update command.

poetry self update

If you want to install prerelease versions, you can use the --preview option.

poetry self update --preview

And finally, if you want to install a specific version you can pass it as an argument to self update.

poetry self update 1.0.0

Note:

If you are still on poetry version < 1.0 use `poetry self:update` instead.

Enable tab completion for Bash, Fish, or Zsh

poetry supports generating completion scripts for Bash, Fish, and Zsh. See poetry help completions for full details, but the gist is as simple as using one of the following:

# Bash
poetry completions bash > /etc/bash_completion.d/poetry.bash-completion

# Bash (Homebrew)
poetry completions bash > $(brew --prefix)/etc/bash_completion.d/poetry.bash-completion

# Fish
poetry completions fish > ~/.config/fish/completions/poetry.fish

# Fish (Homebrew)
poetry completions fish > (brew --prefix)/share/fish/vendor_completions.d/poetry.fish

# Zsh
poetry completions zsh > ~/.zfunc/_poetry

# Zsh (Homebrew)
poetry completions zsh > $(brew --prefix)/share/zsh/site-functions/_poetry

# Zsh (Oh-My-Zsh)
mkdir $ZSH_CUSTOM/plugins/poetry
poetry completions zsh > $ZSH_CUSTOM/plugins/poetry/_poetry

# Zsh (prezto)
poetry completions zsh > ~/.zprezto/modules/completion/external/src/_poetry

Note: you may need to restart your shell in order for the changes to take effect.

For zsh, you must then add the following line in your ~/.zshrc before compinit (not for homebrew setup):

fpath+=~/.zfunc

Introduction

poetry is a tool to handle dependency installation as well as building and packaging of Python packages. It only needs one file to do all of that: the new, standardized pyproject.toml.

In other words, poetry uses pyproject.toml to replace setup.py, requirements.txt, setup.cfg, MANIFEST.in and the newly added Pipfile.

[tool.poetry]
name = "my-package"
version = "0.1.0"
description = "The description of the package"

license = "MIT"

authors = [
    "Sébastien Eustace <[email protected]>"
]

readme = 'README.md'  # Markdown files are supported

repository = "https://github.com/python-poetry/poetry"
homepage = "https://github.com/python-poetry/poetry"

keywords = ['packaging', 'poetry']

[tool.poetry.dependencies]
python = "~2.7 || ^3.2"  # Compatible python versions must be declared here
toml = "^0.9"
# Dependencies with extras
requests = { version = "^2.13", extras = [ "security" ] }
# Python specific dependencies with prereleases allowed
pathlib2 = { version = "^2.2", python = "~2.7", allow-prereleases = true }
# Git dependencies
cleo = { git = "https://github.com/sdispater/cleo.git", branch = "master" }

# Optional dependencies (extras)
pendulum = { version = "^1.4", optional = true }

[tool.poetry.dev-dependencies]
pytest = "^3.0"
pytest-cov = "^2.4"

[tool.poetry.scripts]
my-script = 'my_package:main'

There are some things we can notice here:

  • It will try to enforce semantic versioning as the best practice in version naming.
  • You can specify the readme, included and excluded files: no more MANIFEST.in. poetry will also use VCS ignore files (like .gitignore) to populate the exclude section.
  • Keywords (up to 5) can be specified and will act as tags on the packaging site.
  • The dependencies sections support caret, tilde, wildcard, inequality and multiple requirements.
  • You must specify the python versions for which your package is compatible.

poetry will also detect if you are inside a virtualenv and install the packages accordingly. So, poetry can be installed globally and used everywhere.

poetry also comes with a full fledged dependency resolution library.

Why?

Packaging systems and dependency management in Python are rather convoluted and hard to understand for newcomers. Even for seasoned developers it might be cumbersome at times to create all files needed in a Python project: setup.py, requirements.txt, setup.cfg, MANIFEST.in and the newly added Pipfile.

So I wanted a tool that would limit everything to a single configuration file to do: dependency management, packaging and publishing.

It takes inspiration in tools that exist in other languages, like composer (PHP) or cargo (Rust).

And, finally, I started poetry to bring another exhaustive dependency resolver to the Python community apart from Conda's.

What about Pipenv?

In short: I do not like the CLI it provides, or some of the decisions made, and I think we can make a better and more intuitive one. Here are a few things that I don't like.

Dependency resolution

The dependency resolution is erratic and will fail even if there is a solution. Let's take an example:

pipenv install oslo.utils==1.4.0

will fail with this error:

Could not find a version that matches pbr!=0.7,!=2.1.0,<1.0,>=0.6,>=2.0.0

while Poetry will get you the right set of packages:

poetry add oslo.utils=1.4.0

results in :

  - Installing pytz (2018.3)
  - Installing netifaces (0.10.6)
  - Installing netaddr (0.7.19)
  - Installing oslo.i18n (2.1.0)
  - Installing iso8601 (0.1.12)
  - Installing six (1.11.0)
  - Installing babel (2.5.3)
  - Installing pbr (0.11.1)
  - Installing oslo.utils (1.4.0)

This is possible thanks to the efficient dependency resolver at the heart of Poetry.

Here is a breakdown of what exactly happens here:

oslo.utils (1.4.0) depends on:

  • pbr (>=0.6,!=0.7,<1.0)
  • Babel (>=1.3)
  • six (>=1.9.0)
  • iso8601 (>=0.1.9)
  • oslo.i18n (>=1.3.0)
  • netaddr (>=0.7.12)
  • netifaces (>=0.10.4)

What interests us is pbr (>=0.6,!=0.7,<1.0).

At this point, poetry will choose pbr==0.11.1 which is the latest version that matches the constraint.

Next it will try to select oslo.i18n==3.20.0 which is the latest version that matches oslo.i18n (>=1.3.0).

However this version requires pbr (!=2.1.0,>=2.0.0) which is incompatible with pbr==0.11.1, so poetry will try to find a version of oslo.i18n that satisfies pbr (>=0.6,!=0.7,<1.0).

By analyzing the releases of oslo.i18n, it will find oslo.i18n==2.1.0 which requires pbr (>=0.11,<2.0). At this point the rest of the resolution is straightforward since there is no more conflict.

Resources

Issues
  • pip install -e . equivalent?

    pip install -e . equivalent?

    We cannot run pip install -e . because there is no setup.py. What would be the way to achieve this using poetry?

    opened by kootenpv 150
  • Ability to override/ignore sub-dependencies

    Ability to override/ignore sub-dependencies

    • [x] I have searched the issues of this repo and believe that this is not a duplicate.

    (However, it is related to https://github.com/sdispater/poetry/issues/436).

    Issue

    In the dark, old world of Python packaging, sub-dependencies are handled very poorly. If I recall correctly, pip will happily install a sub-dependency despite conflicting versions being specified by two direct dependencies... in fact I think which version it ends up installing depends on the order in requirements.txt. Yuck! Only very recently has it even started issuing a warning for cases like this.

    In contrast, poetry does this right. It computes the entire dependency tree and will complain if there are conflicts anywhere in the tree.

    But... many packages out there are not specifying their dependencies properly. Even if they are, there's always the possibility that their specified dependencies are a tighter range than they strictly need to be.

    Is there a way to tell Poetry to force a specific version (or version) range of a dependency in cases like this — or in other words, to ignore a dependency specification of another dependency somewhere in the tree? If not, should there be?

    Feature 
    opened by zehauser 73
  • peotry version doesn't bump the value in __version__

    peotry version doesn't bump the value in __version__

    $ poetry version 0.1.1
    Bumping version from 0.1.0 to 0.1.1
    $ grep version pyproject.toml 
    version = "0.1.1"
    $ grep version */__init__.py
    src/__init__.py:__version__ = '0.1.0'
    $ poetry --version
    Poetry 0.9.0
    

    I don't know if it's intended or not. A way to do that safely is to parse the root __init__.py, detect __version__, back it up, extract the ast, bump the version string and replace it, then extract the new ast and compare the result. If both ast are the same, except for the version, the file semantics have been preserved. Otherwise, rollback the change and display an error message stating we can't bump the version safely.

    CLI Feature 
    opened by ksamuel 67
  • Support for .env files

    Support for .env files

    • [x] I have searched the issues of this repo and believe that this is not a duplicate.

    Issue

    First off I really like poetry- I'd actually only recently migrated over to pipenv but I already see the advantages of poetry and would ideally like to use it full time.

    I primarily work with Django and other web frameworks that can require a large amount of configuration which- when following 12 factor app practices- involves lots of environment variables that necessitates the use of a .env file.

    Is there a possibility of adding in .env file support, specifically for poetry's run command so that the resulting command runs both in the virtualenv and with the environment as configured in the .env file?

    opened by ptink 62
  • Add support for `scripts`

    Add support for `scripts`

    It would be nice if poetry supported the scripts feature of setuptools (note: this is not the same as entry points).

    I tried using a custom build script but it seems to be ignored by poetry when building wheels.

    Feature 
    opened by ojii 59
  • Poetry 0.12.3 uses Python 2.7.10 despite specifying 3.7.0

    Poetry 0.12.3 uses Python 2.7.10 despite specifying 3.7.0

    • [x] I am on the latest Poetry version.
    • [x] I have searched the issues of this repo and believe that this is not a duplicate.
    • [x] If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).
    • OS version and name: macOS Mojave
    • Poetry version: 0.12.3
    • Link of a Gist with the contents of your pyproject.toml file:

    Issue

    No matter what I do, Poetry uses Python 2.7.10.

    For instance, I've downloaded and specified Python 3.7.0 with pyenv:

    $ pyenv install 3.7.0
    $ pyenv local 3.7.0
    

    My pyproject.toml specifies:

    [tool.poetry.dependencies]
    python = "3.7.0"
    ...
    

    Yet poetry update yields:

    [SolverProblemError]
    The current supported Python versions are 2.7.10
    Because hug (2.4.1) requires Python >=3.4
     and no versions of hug match >2.4.1,<3.0.0, hug is forbidden.
    So, because <...> depends on prodigy (1.6.1) which depends on hug (>=2.4.1,<3.0.0), version solving failed.
    

    I'm completely mystified.

    Infuriatingly, if I instead specify python = "3.2" Poetry will gladly use Python 3.2...

    Init CLI Feature 
    opened by maxcountryman 53
  • Some tests fail because of wrong rights on /foo

    Some tests fail because of wrong rights on /foo

    • [x] I am on the latest Poetry version.

    • [x] I have searched the issues of this repo and believe that this is not a duplicate.

    • [x] If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

    • OS version and name: openSUSE/Tumbleweed (Linux)

    • Poetry version: 1.0.0b8

    Issue

    Plenty of tests fail because of the traceback similar to this one (from ):

    [   88s] ____________________________ test_add_no_constraint ____________________________
    [   88s] 
    [   88s] app = <tests.console.conftest.Application object at 0x7fd532dff4a8>
    [   88s] repo = <tests.console.conftest.Repository object at 0x7fd532b587b8>
    [   88s] installer = <poetry.installation.noop_installer.NoopInstaller object at 0x7fd532bc1470>
    [   88s] 
    [   88s]     def test_add_no_constraint(app, repo, installer):
    [   88s]         command = app.find("add")
    [   88s]         tester = CommandTester(command)
    [   88s]     
    [   88s]         repo.add_package(get_package("cachy", "0.1.0"))
    [   88s]         repo.add_package(get_package("cachy", "0.2.0"))
    [   88s]     
    [   88s] >       tester.execute("cachy")
    [   88s] 
    [   88s] tests/console/commands/test_add.py:19: 
    [   88s] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
    [   88s] /usr/lib/python3.7/site-packages/cleo/testers/command_tester.py:61: in execute
    [   88s]     self._status_code = command.run(args, self._io)
    [   88s] /usr/lib/python3.7/site-packages/clikit/api/command/command.py:116: in run
    [   88s]     return self.handle(self.parse(args), io)
    [   88s] /usr/lib/python3.7/site-packages/clikit/api/command/command.py:120: in handle
    [   88s]     status_code = self._do_handle(args, io)
    [   88s] /usr/lib/python3.7/site-packages/clikit/api/command/command.py:163: in _do_handle
    [   88s]     self._dispatcher.dispatch(PRE_HANDLE, event)
    [   88s] /usr/lib/python3.7/site-packages/clikit/api/event/event_dispatcher.py:22: in dispatch
    [   88s]     self._do_dispatch(listeners, event_name, event)
    [   88s] /usr/lib/python3.7/site-packages/clikit/api/event/event_dispatcher.py:89: in _do_dispatch
    [   88s]     listener(event, event_name, self)
    [   88s] poetry/console/config/application_config.py:86: in set_env
    [   88s]     env = env_manager.create_venv(io)
    [   88s] poetry/utils/env.py:587: in create_venv
    [   88s]     self.build_venv(str(venv), executable=executable)
    [   88s] poetry/utils/env.py:647: in build_venv
    [   88s]     build(path)
    [   88s] /usr/lib64/python3.7/venv/__init__.py:60: in create
    [   88s]     context = self.ensure_directories(env_dir)
    [   88s] /usr/lib64/python3.7/venv/__init__.py:107: in ensure_directories
    [   88s]     create_if_needed(env_dir)
    [   88s] /usr/lib64/python3.7/venv/__init__.py:96: in create_if_needed
    [   88s]     os.makedirs(d)
    [   88s] /usr/lib64/python3.7/os.py:211: in makedirs
    [   88s]     makedirs(head, exist_ok=exist_ok)
    [   88s] /usr/lib64/python3.7/os.py:211: in makedirs
    [   88s]     makedirs(head, exist_ok=exist_ok)
    [   88s] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
    [   88s] 
    [   88s] name = '/foo', mode = 511, exist_ok = False
    [   88s] 
    [   88s]     def makedirs(name, mode=0o777, exist_ok=False):
    [   88s]         """makedirs(name [, mode=0o777][, exist_ok=False])
    [   88s]     
    [   88s]         Super-mkdir; create a leaf directory and all intermediate ones.  Works like
    [   88s]         mkdir, except that any intermediate path segment (not just the rightmost)
    [   88s]         will be created if it does not exist. If the target directory already
    [   88s]         exists, raise an OSError if exist_ok is False. Otherwise no exception is
    [   88s]         raised.  This is recursive.
    [   88s]     
    [   88s]         """
    [   88s]         head, tail = path.split(name)
    [   88s]         if not tail:
    [   88s]             head, tail = path.split(head)
    [   88s]         if head and tail and not path.exists(head):
    [   88s]             try:
    [   88s]                 makedirs(head, exist_ok=exist_ok)
    [   88s]             except FileExistsError:
    [   88s]                 # Defeats race condition when another thread created the path
    [   88s]                 pass
    [   88s]             cdir = curdir
    [   88s]             if isinstance(tail, bytes):
    [   88s]                 cdir = bytes(curdir, 'ASCII')
    [   88s]             if tail == cdir:           # xxx/newdir/. exists if xxx/newdir exists
    [   88s]                 return
    [   88s]         try:
    [   88s] >           mkdir(name, mode)
    [   88s] E           PermissionError: [Errno 13] Permission denied: '/foo'
    [   88s] 
    [   88s] /usr/lib64/python3.7/os.py:221: PermissionError
    

    Complete build log

    Bug 
    opened by mcepl 52
  • How do I uninstall packages that have been removed from pyproject.toml?

    How do I uninstall packages that have been removed from pyproject.toml?

    • [x] I have searched the issues of this repo and believe that this is not a duplicate.
    • [x] I have searched the documentation and believe that my question is not covered.

    Question

    pipenv has pipenv clean which removes all packages that are no longer in Pipfile.lock from the virtualenv. What is the equivalent with poetry? The docs say there is no need for pipenv sync and pipenv clean due to the remove command https://github.com/sdispater/poetry#remove-command

    But how does this work? I would need to run poetry remove XXX against all my virtualenvs - manually keeping track of all packages that have been removed and remembering to remove them myself?

    Is there not any way to sync my poetry.lock to my virtualenv to ensure the virtualenv only has the packages specified in poetry.lock installed?

    I have a virtualenv on each box I deploy to, and keep pyproject.toml and poetry.lock under source code control. I then want a way to ensure each of those virtualenvs only has the packages in poetry.lock installed.

    Feature 
    opened by rectalogic 45
  • Include installation instructions for python3

    Include installation instructions for python3

    • [x] I have searched the issues of this repo and believe that this is not a duplicate.

    Issue

    The README states as the ideal way to install Poetry:

    curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python
    

    But, on an Ubuntu Xenial system with only Python 3 installed, this leads to the error bash: python: command not found. If I simply pipe the curl command through python3 instead then it succeds, but then I get:

    $ poetry install
    /usr/bin/env: 'python': No such file or directory
    

    This is because the top of the installed file at $HOME/.poetry/bin/poetry contains #! /usr/bin/env python.

    If, instead, I install poetry with pip3 install poetry, then head -n 1 $(which poetry) shows #!/usr/bin/python3 at the top of the file, which works perfectly.

    Ubuntu, from 18.04 Xenial onwards, includes only Python 3 by default. And the minimal version of Xenial doesn't come with Python out of the box at all.

    If you install Python 3 on Ubuntu, the binary that's installed is python3. python doesn't exist unless you've also installed Python 2. This deliberately follows PEP 394:

    • python2 will refer to some version of Python 2.x.
    • python3 will refer to some version of Python 3.x.
    • for the time being, all distributions should ensure that python refers to the same target as python2.
    • however, end users should be aware that python refers to python3 on at least Arch Linux (that change is what prompted the creation of this PEP), so python should be used in the shebang line only for scripts that are source compatible with both Python 2 and 3.
    • in preparation for an eventual change in the default version of Python, Python 2 only scripts should either be updated to be source compatible with Python 3 or else to use python2 in the shebang line.

    Although the PEP states "python should be used in the shebang line only for scripts that are source compatible with both Python 2 and 3" I'm not sure that this is compatible with the statement "all distributions should ensure that python refers to the same target as python2", because this means that if a system doesn't have Python 2 then the python binary won't exist. I think scripts have to do their best to use python3 if they know it's supported, and most I've encountered do.

    I think maybe it would be good if the suggested install command was:

    curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | ( python3 || python )
    

    Or maybe you could provide a bash script (if you can rely on bash being available on all relevant systems) so that you could hide the logic of determining the Python version from the user:

    curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.sh | bash
    

    Or simply say in the README:

    One of:
    
    ``` bash
    curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python3
    # or
    curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python
    

    And that the script would set up the poetry binary with either #! /usr/bin/env python3 for Python 3, or #! /usr/bin/env python for Python 2 (which would then allow for the possibility of python changing to Python 3 at some point).

    Installer 
    opened by nottrobin 45
  • Feature: Add poetry as pre-commit hook

    Feature: Add poetry as pre-commit hook

    Pull Request Check List

    Resolves: #2457

    • [x] Added tests for changed code. (no code was changed)
    • [x] Updated documentation for changed code.

    I created this draft PR for easier discussion in the issue #2457 .

    Feature 
    opened by Cielquan 43
  • Install only dev dependencies

    Install only dev dependencies

    • [x] I have searched the issues of this repo and believe that this is not a duplicate.
    • [x] I have searched the documentation and believe that my question is not covered.

    Feature Request

    The documentation mentions "The --dev-only option is now deprecated. You should use the --only dev notation instead." (https://python-poetry.org/docs/master/cli/)

    However, this functionality is not actually available in poetry 1.1.11 (see poetry install --help). It would be great if you could bring it back (there have been other issues related to this).

    Feature Triage 
    opened by juliuskittler 0
  • Virtual environment name mapping - make more portable, add ability to override, store as project ID?

    Virtual environment name mapping - make more portable, add ability to override, store as project ID?

    • [x] I have searched the issues of this repo and believe that this is not a duplicate.
    • [x] I have searched the documentation and believe that my question is not covered.

    Feature Request

    Poetry, if allowed to automatically manage them, creates virtual environments with names roughly like project name-hash-python version. This design choice makes life simple in some cases, but adds a hidden state to the project that complicates things in some situations. Mainly, the hash depends on information outside the scope of the project (e.g. project folder path), which is a questionable design choice in my opinion. I think that adding a little flexibility to override this behaviour, or even change how to hash is generated / stored would make Poetry a better tool overall.

    Just to mention a few cases where the current name mapping causes problems: #3459 and #4654. Briefly, the hash in the virtual env name seems to depend on the path where the project is located and perhaps other things. Rename the project folder - poetry will create a new virtual env and you'll need to reinstall all the packages from zero; plus the old env will linger forgotten. If you share workspace settings on multiple computers (stored in project folders, e.g. for VSCode), the env path will need to be updated each time you switch to another computer; similar in multi-user situations.

    @sinoroc asks in #3459, how a design change would help Poetry? (S)He also mentions that the current design makes things simpler by not having to remember the virtual env's name, like you need to if you use venv or Conda. I think Poetry only makes things simpler if you use it the way it's supposed to be used, but doesn't have the flexibility to move beyond that. New users, who are not familiar with virtual environment management, might find the automated environment creation useful ... until they rename the project folder ... and then get a big surprise when their environment is gone without warning. Moreover, while managing workspace settings for VSCode (example above) has nothing to do with Poetry, easier integration with other tools is better for Poetry, isn't it?

    In my case, I use pyenv (pyenv-win on Windows) to manage Python versions; manage virtual environments with venv, and let poetry manage packages inside virtual envs. However, the only thing I need venv for, is to get the virtual environment name I want - if only poetry would let me change the name mapping, I could drop venv from the pipeline.

    OK, OK, so why not store the virtual environment in the project folder? Poetry can already do that, so problem solved, right? Well, not really. What if I'm moving between Linux and PC? Surely the packages cannot be shared. And what if I keep code on Google/One/other cloud drive and don't have gigabytes to store all the packages for the dependencies? Again, Poetry covers some common cases but it could do better!

    I believe that the problem here is how the hash is generated. It depends on things that are outside the scope of the project, thus reducing portability / consistency even between different folders on the same PC. Besides being a design choice, I don't see why it cannot be done differently. While I'm not sure what the best solution is, here are some ideas to start with:

    1. More manual control over the virtual env names (as suggested in #3459). Adds some complexity, but makes advanced users happy by allowing them to do things their own way. Don't be Apple.
    2. Store hash in poetry.toml with other local settings. First time the enviroment is created, the hash can be generated randomly, and subsequent virtual environment accesses (including creation) would reuse it and combine it with python version etc. Basically, assign the project some kind of ID that can be shared between computers / users as they want. Instead of just the hash, virtual env names could be stored. No hidden state; no dependency on location; better portability; and this could be done completely automatically without user interaction maintaining current level of simplicity.

    1 & 2 aren't mutually exclusive, in fact, I think the best outcome would be achieved by implementing both. Overall, I'm sure that there are several points to iron out, such as how to enable this behaviour (additional command line switches / configuration settings?), but, overall, I don't think these changes would have negative side effects.

    Feature Triage 
    opened by zEdS15B3GCwq 0
  • Segfault building ARM64 docker container

    Segfault building ARM64 docker container

    • [x] I am on the latest Poetry version.

    • [x] I have searched the issues of this repo and believe that this is not a duplicate.

    • [x] If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

    • OS version and name: OS X Monterey 12.0

    • Poetry version: Tested multiple versions. This fails on anything above 1.1.0

    • Link of a Gist with the contents of your pyproject.toml file: pyproject.toml and Dockerfile

    Issue

    I'm trying to create a multi-platform image of my services to run on x86 and ARM machines. In the past, we have just built and run our images on x86. While trying to add support for ARM64, I get a seg fault with even the most basic dockerfile and pyproject.toml. I tried multiple versions of poetry and the only one I was able to get this to run successfully with was 1.0.5. Anything above 1.1.0 fails.

    To reproduce:

    On an M1 Mac, simply build a container using a barebones pyproject.toml. docker build -t mycompany/my-service .

    On any other machine, you can use buildx:

    docker buildx create --use
    docker buildx build -t mycompany/my-service --platform=linux/arm64 .
    

    Result:

    Even with no dependencies to install, you will get a segfault:

    #11 0.332 Installing dependencies from lock file
    #11 0.354 Segmentation fault
    ------
    Dockerfile:38
    --------------------
      36 |     
      37 |     COPY ["pyproject.toml", "poetry.lock", "/app/"]
      38 | >>> RUN poetry install
      39 |     
      40 |     
    --------------------
    error: failed to solve: process "/bin/sh -c poetry install" did not complete successfully: exit code: 139
    

    You can swap the poetry version in the dockerfile to 1.0.5 and try again and see that it builds successfully.

    Bug Triage 
    opened by colinchilds 0
  • Time until `poetry-core` release 1.1.0a7?

    Time until `poetry-core` release 1.1.0a7?

    Hi,

    I'm dealing with https://github.com/python-poetry/poetry/issues/4523 across quite a few poetry projects. The problem appeared to be some regression between poetry-core 1.0.4 and 1.0.5. Pinning the poetry client's poetry-core==1.0.4 seems to work in the short-term, but I'm not crazy about the hack/patch.

    poetry itself depends on poetry-core^1.1.0a6, which was released on July 30th, 2021, when the latest 1.0.x release was 1.0.3 on April 2021. Since then, the 1.0.x releases have seen updates up to 1.0.7, notably where 1.0.6 claims to have fixed this (via #207).

    https://github.com/python-poetry/poetry/blob/e1235188d09e3688338867ae0897b79251c63bf9/pyproject.toml#L37

    My question is: would it be possible to release 1.1.0a7 that includes the recent updates to the 1.0.x releases so that poetry is installed with a version of poetry-core that addresses this issue?

    • [x] I have searched the issues of this repo and believe that this is not a duplicate.
    • [x] I have searched the documentation and believe that my question is not covered.
    opened by dataframing 0
  • Install R in a poetry env

    Install R in a poetry env

    • [x] I have searched the issues of this repo and believe that this is not a duplicate.
    • [x] I have searched the documentation and believe that my question is not covered.

    Issue

    I have a poetry environment that I spawn with poetry shell. I would like to install R in this local environment and then install rpy2 to call some R functions from python. How can I achieve this?

    opened by ZenBel 0
  • Poetry can't add any package anymore in a reasonable amount of time

    Poetry can't add any package anymore in a reasonable amount of time

    • [x] I have searched the issues of this repo and believe that this is not a duplicate.
    • [x] I have searched the documentation and believe that my question is not covered.

    Issue

    Here's my env:

    • macOS Big Sur
    • pyenv (Python 3.10)
    • Poetry version 1.1.12 (installed with pipx)
    • My config
    $ poetry config --list
    cache-dir = "/myPath"
    experimental.new-installer = true
    installer.parallel = true
    virtualenvs.create = true
    virtualenvs.in-project = true
    virtualenvs.path = "{cache-dir}/virtualenvs"  # /myPath/virtualenvs
    

    I have worked with poetry smoothly so far. Suddenly, it looks like poetry can't resolve dependencies anymore in a reasonable amount of time. It happens, for example, with pytest. This is my starting pyproject.toml

    click to expand my pyproject.toml
    [tool.poetry]
    name = "foo"
    version = "0.1.0"
    description = ""
    authors = ["Foo <[email protected]>"]
    
    # ciao
    [tool.poetry.dependencies]
    python = "^3.9"
    
    [tool.poetry.dev-dependencies]
    
    [build-system]
    requires = ["poetry-core>=1.0.0"]
    build-backend = "poetry.core.masonry.api"
    

    if I run $ poetry add pytest --dev -vvv

    I get this output (ie: poetry stuck in Resolving dependencies... )

    click to expand command output
    Using virtualenv: /projectPath/foo/.venv
    PyPI: 147 packages found for pytest *
    Using version ^6.2.5 for pytest
    
    Updating dependencies
    Resolving dependencies...
       1: fact: foo is 0.1.0
       1: derived: foo
       1: fact: foo depends on pytest (^6.2.5)
       1: fact: foo depends on pytest (^6.2.5)
       1: selecting foo (0.1.0)
       1: derived: pytest (>=6.2.5,<7.0.0)
    PyPI: 1 packages found for pytest >=6.2.5,<7.0.0
       1: fact: pytest (6.2.5) depends on attrs (>=19.2.0)
       1: fact: pytest (6.2.5) depends on iniconfig (*)
       1: fact: pytest (6.2.5) depends on packaging (*)
       1: fact: pytest (6.2.5) depends on pluggy (>=0.12,<2.0)
       1: fact: pytest (6.2.5) depends on py (>=1.8.2)
       1: fact: pytest (6.2.5) depends on toml (*)
       1: fact: pytest (6.2.5) depends on atomicwrites (>=1.0)
       1: fact: pytest (6.2.5) depends on colorama (*)
       1: selecting pytest (6.2.5)
       1: derived: colorama
       1: derived: atomicwrites (>=1.0)
       1: derived: toml
       1: derived: py (>=1.8.2)
       1: derived: pluggy (>=0.12,<2.0)
       1: derived: packaging
       1: derived: iniconfig
       1: derived: attrs (>=19.2.0)
    PyPI: 42 packages found for colorama *
    ^C   1: Version solving took 93.503 seconds.
       1: Tried 1 solutions.
    

    As you can see, I stopped the process after 96s. I can't understand what is going on and why it suddenly started taking so long for installing just pytest. How can I fix it up?

    PS: this issue started after installing ruamel.yaml with poetry. I'm quite sure it was just a coincidence. But that is what happened.

    PPS: the issue persists also after clearing cache with $ poetry cache clear --all pypi

    opened by floatingpurr 1
  • Poetry doesn't check extra sources for package

    Poetry doesn't check extra sources for package

    • [x] I am on the latest Poetry version.
    • [x] I have searched the issues of this repo and believe that this is not a duplicate.
    • [x] If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).
    • OS version and name: Ubuntu 20.04.3 LTS (Focal Fossa)
    • Poetry version: 1.1.12
    • Contents of your pyproject.toml file:
    [tool.poetry]
    name = "shit"
    version = "0.1.0"
    description = ""
    authors = ["None"]
    
    [tool.poetry.dependencies]
    python = "^3.7"
    tensorflow = "1.15.5"
    
    [tool.poetry.dev-dependencies]
    
    [[tool.poetry.source]]
    name = "tensorflow"
    url = "https://tf.kmtea.eu/whl/stable.html"
    
    [build-system]
    requires = ["poetry-core>=1.0.0"]
    build-backend = "poetry.core.masonry.api"
    

    Issue

    Poetry is incapable of finding a package from a custom source. The package is also part of pypi, but not for arm64 architectures, so I need to add a custom source to search for it, but it doesn't try to look for it there. This results on poetry add tensorflow==1.15.5 failing on arm64 architectures.

    I have added a custom source where this is available (and it works if you do pip install tensorflow==1.15.5 -f https://tf.kmtea.eu/whl/stable.html) but poetry never looks in that source for the package, so the build fails with:

    Unable to find installation candidates for tensorflow (1.15.5)
    
      at ~/.poetry/lib/poetry/installation/chooser.py:74 in choose_for
           70│             links.append(link)
           71│
           72│         if not links:
           73│             raise RuntimeError(
        →  74│                 "Unable to find installation candidates for {}".format(package)
           75│             )
           76│
           77│         # Get the best link
           78│         chosen = max(links, key=lambda link: self._sort_key(package, link))
    

    I have also tried with:

    [tool.poetry.dependencies]
    python = "^3.7"
    tensorflow = {version = "1.15.5", source = "tensorflow"}
    

    but it doesn't work either.

    Any tips? Thanks!

    Bug Triage 
    opened by JaviFuentes94 1
  • Add option to use current active python to create venv (

    Add option to use current active python to create venv ("pyenv way")

    The "pyenv-way" for switching/creating venvs as described in the docs doesn't work anymore when using the install-poetry.py script.

    This Draft-PR is a proof-of-concept to see if it's possible to detect the current running python in the shell, set by pyenv and bring back that functionality and make it also available when installing poetry via pipx.

    It will probably never be included in poetry like this, as we don't want to rely on third-party tools if not necessary. But this could be a starting point to find out how to integrate it via a plugin.(Maybe it can be implemented, because I've found a generic way. So it's up to @sdispater if such a solution will be included.)

    This PR adds in opt-in option virtualenvs.prefer-active-python. If set to true poetry will try to use the current running python of the shell for creating the venv.

    Would be happy if some people could test their usecase with this MR.

    Install with pipx:

    pip install pipx
    pipx install [email protected] 'poetry @ git+https://github.com/finswimmer/[email protected]
    [email protected] --version
    

    Install with install-poetry.py script:

    curl -sSL https://install.python-poetry.org | python3 - --git "https://github.com/finswimmer/[email protected]'"
    
    opened by finswimmer 0
  • Can't add plugin in relative directory

    Can't add plugin in relative directory

    • [ ] I am on the latest Poetry version.
    • [x] I have searched the issues of this repo and believe that this is not a duplicate.
    • [ x] If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).
    • OS version and name: Fedora 34
    • Poetry version: 1.2.0a2

    Issue

    If you install plugin from relative directory poetry failes with error that there is no such directory. E.g. poetry plugin add ../my_plugin/dist/my_plugin-0.1.0-py3-none-any.whl results with: Directory ../my_plugin/dist/my_plugin-0.1.0-py3-none-any.whl does not exist

    If I run plugin add giving absolute path poetry adds plugin successfully.

    Bug Triage 
    opened by raven-wing 0
  • Documentation improvement for issue #4844

    Documentation improvement for issue #4844

    Resolves: #4844

    Small docs fix that adds a warning box to suggest using quotes on some shells such as Mac Zsh.

    • [ ] Added tests for changed code. NO CHANGED CODE - ONLY DOCS IN PR
    • [x] Updated documentation for changed code.
    opened by ttamg 3
Releases(1.1.12)
Owner
Poetry
Python packaging and dependency management made easy
Poetry
Python PyPi staging server and packaging, testing, release tool

devpi: PyPI server and packaging/testing/release tool This repository contains three packages comprising the core devpi system on the server and clien

null 506 Nov 24, 2021
Solaris IPS: Image Packaging System

Solaris Image Packaging System Introduction The image packaging system (IPS) is a software delivery system with interaction with a network repository

Oracle 47 Nov 24, 2021
Simple Library Management made with Python

Installation pip install mysql-connector-python NOTE: You must make a database (library) & and table (books, student) to hold all data. Languange and

SonLyte 10 Oct 21, 2021
An installation and dependency system for Python

Pyflow Simple is better than complex - The Zen of Python Pyflow streamlines working with Python projects and files. It's an easy-to-use CLI app with a

David O'Connor 943 Dec 3, 2021
pip-run - dynamic dependency loader for Python

pip-run provides on-demand temporary package installation for a single interpreter run. It replaces this series of commands (or their Windows equivale

Jason R. Coombs 61 Nov 20, 2021
:package: :fire: Python project management. Manage packages: convert between formats, lock, install, resolve, isolate, test, build graph, show outdated, audit. Manage venvs, build package, bump version.

THE PROJECT IS ARCHIVED Forks: https://github.com/orsinium/forks DepHell -- project management for Python. Why it is better than all other tools: Form

DepHell 1.7k Dec 3, 2021
Easy to use, fast, git sourced based, C/C++ package manager.

Yet Another C/C++ Package Manager Easy to use, fast, git sourced based, C/C++ package manager. Features No need to install a program, just include the

null 28 Nov 28, 2021
Install and Run Python Applications in Isolated Environments

pipx — Install and Run Python Applications in Isolated Environments Documentation: https://pipxproject.github.io/pipx/ Source Code: https://github.com

null 4.3k Dec 2, 2021
A set of tools to keep your pinned Python dependencies fresh.

pip-tools = pip-compile + pip-sync A set of command line tools to help you keep your pip-based packages fresh, even when you've pinned them. You do pi

Jazzband 5.3k Dec 2, 2021
A PyPI mirror client according to PEP 381 http://www.python.org/dev/peps/pep-0381/

This is a PyPI mirror client according to PEP 381 + PEP 503 http://www.python.org/dev/peps/pep-0381/. bandersnatch >=4.0 supports Linux, MacOSX + Wind

Python Packaging Authority 272 Nov 30, 2021
The Python Package Index

Warehouse Warehouse is the software that powers PyPI. See our development roadmap, documentation, and architectural overview. Getting Started You can

Python Packaging Authority 2.8k Nov 26, 2021
The Python package installer

pip - The Python Package Installer pip is the package installer for Python. You can use pip to install packages from the Python Package Index and othe

Python Packaging Authority 7.6k Dec 1, 2021
Python Development Workflow for Humans.

Pipenv: Python Development Workflow for Humans [ ~ Dependency Scanning by PyUp.io ~ ] Pipenv is a tool that aims to bring the best of all packaging wo

Python Packaging Authority 22.5k Dec 3, 2021
A PyPI mirror client according to PEP 381 http://www.python.org/dev/peps/pep-0381/

This is a PyPI mirror client according to PEP 381 + PEP 503 http://www.python.org/dev/peps/pep-0381/. bandersnatch >=4.0 supports Linux, MacOSX + Wind

Python Packaging Authority 270 Nov 26, 2021
PokerFace is a Python package for various poker tools.

PokerFace is a Python package for various poker tools. The following features are present in PokerFace... Types for cards and their componen

Juho Kim 4 Sep 25, 2021
OS-agnostic, system-level binary package manager and ecosystem

Conda is a cross-platform, language-agnostic binary package manager. It is the package manager used by Anaconda installations, but it may be used for

Conda 4.4k Nov 24, 2021
local pypi server (custom packages and auto-mirroring of pypi)

localshop A PyPI server which automatically proxies and mirrors PyPI packages based upon packages requested. It has support for multiple indexes and t

Michael van Tellingen 374 Nov 23, 2021
OS-agnostic, system-level binary package manager and ecosystem

Conda is a cross-platform, language-agnostic binary package manager. It is the package manager used by Anaconda installations, but it may be used for

Conda 4.4k Nov 26, 2021
Package manager based on libdnf and libsolv. Replaces YUM.

Dandified YUM Dandified YUM (DNF) is the next upcoming major version of YUM. It does package management using RPM, libsolv and hawkey libraries. For m

null 923 Nov 28, 2021