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 61
  • 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 58
  • 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...

    Setup 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
  • 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
  • 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
  • Support generation of poetry manged setup.py file

    Support generation of poetry manged setup.py file

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

    Issue

    As things stand today, poetry packages cannot be installed using pip or any other package managers from a VCS. This is useful when working with unreleased/unpublished versions of dependencies, where dependencies are managed by 'pip' or another tool. This was briefly touched on in #34 for a similar use case.

    With this in mind, it could be great if poetry provided a solution, in a limited capacity, similar to what is implemented by poetry-setup. In order to achieve this, poetry could provide a command, eg: poetry setuptools:setupfile, that generates a usable setup.py file using the mechanism used today by SdistBuilder.

    In theory, this could be migrated to be a plugin once #693 is implemented.

    As an example. this, if implemented, could be used by projects as a pre-commit hook to generate setup.py file on commit. This should allow projects using pip etc. to install unpublished projects developed using poetry (if the maintainer wants it).

    In addition to the above use case, this also allows for tools like PyCharm etc., to auto detect requirements and metadata.

    Can follow this up with a proposed implementation PR.

    Relates-to: #34

    Feature 
    opened by abn 43
  • github: configure dependency detection

    github: configure dependency detection

    This change adds dependabot configuration with updates disabled to allow for restriction of manifest file selection used by the dependency graph.

    Ref: https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates

    opened by abn 0
  • Release archive contains vulnerable cryptography library

    Release archive contains vulnerable cryptography library

    • [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.
    • OS version and name: Ubuntu 20.04
    • Poetry version: 1.1.11

    Issue

    When installing poetry, cryptography is installed as a runtime dependency. This appears to be included to support urllib3, which is apparently included to support requests. The version of cryptography in the py3.5 directory is 3.2.1, which contains critical vulnerability CVE-2020-36242. I understand support for python 2.7 and 3.5 will be removed in the next major release, so that should take care of this issue, but I'm not sure when that will be available. Can 1.11.x be patched to either remove cryptography or upgrade it to at least version 3.3.2?

    Bug Triage 
    opened by jwilk71 0
  • Executor: Remove duplicate entry with dry-run argument

    Executor: Remove duplicate entry with dry-run argument

    Pull Request Check List

    Resolves: #3097

    • [x] Added tests for changed code. I adapted the test in the tests/console/commands/plugin/test_remove.py file to reflect the bug fix.
    • [ ] Updated documentation for changed code.

    Apart from running the ci linting steps and pytest locally for both python 3.6 and 3.8, I also tested the code by running

    docker run --rm -i --entrypoint bash python:3.8 <<EOF
    set -e
    python -m pip install -q git+https://github.com/mmacchia/[email protected]/3097
    python -m poetry new foobar
    pushd foobar
    sed -i /pytest/d pyproject.toml
    python -m poetry add --dry-run pycowsay
    python -m poetry run pip list
    EOF
    

    The corresponding output is:

    Created package foobar in foobar
    /foobar /
    Creating virtualenv foobar-lWDpn5M1-py3.8 in /root/.cache/pypoetry/virtualenvs
    Using version ^0.0.0.1 for pycowsay
    
    Updating dependencies
    Resolving dependencies...
    
    Writing lock file
    
    Package operations: 1 install, 0 updates, 0 removals
    
      • Installing pycowsay (0.0.0.1)
    Package    Version
    ---------- -------
    pip        21.2.4
    setuptools 58.1.0
    wheel      0.37.0
    

    As expected, the command poetry add --dry-run pycowsay yielded a single output (• Installing pycowsay (0.0.0.1)) and did not add the package to the project (see the output of poetry run pip list).

    Finally, the output in the case not self._enabled holds true is still returned since that is taken care of by the boolean output of theself._should_write_operation(operation) function.

    Please feel free to get in touch if I can help adding more test cases for the --dry-run argument or the _enabled flag and to add any feedback. I would be happy to improve/clarify the code in this PR.

    opened by mmacchia 1
  • Additional source is being ignored while inheriting dependencies

    Additional source is being ignored while inheriting dependencies

    • [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 Big Sur 11.6

    • Poetry version: 1.1.11

    Issue

    Hi guys! I'm using poetry for loading multiple projects and they depend on one another with the following structure:

    .
    ├── project_1
    │   └── pyproject.toml
    └── project_2
        └── pyproject.toml
    

    project_1/pyproject.toml

    [[tool.poetry.source]]
    name = "artifactory"
    url = "https://pypi.example.com"
    default = true
    
    [tool.poetry.dependencies]
    private_package = {version ="0.0.1", source = "artifactory"}
    

    project_2/pyproject.toml

    [tool.poetry.dependencies]
    requests = "2.26.0"
    fastapi = "0.65.3"
    
    [tool.poetry.dependencies.project_1]
    path = "../project_1"
    

    And while I'm trying to execute poetry install or poetry update in project_2 it fails to find private_package (despite the same commands are working well inside project_1) It makes me think that additional source, which was added in project_1 doesn't affect project_2

    Can you please tell me if that's working well as designed and I'm trying to do something which is not supported entirely or if I'm misusing a tool and there's a lack of configurations?

    Bug Triage 
    opened by velykanov 1
  • Private PyPi URL for publishing and downloading is not the same

    Private PyPi URL for publishing and downloading is not the same

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

    Issue

    Hi,

    First thank you for your effort on this library. I have been trying to add a dependency from a private pypi repo and I followed the docs and other internet resources to be able to download and upload the package from/to my private PyPi server. However, after some experiments, I realised that the download and upload just worked using different URLs.

    For downloading I used the following configuration in pyproject.toml, which follows Poetry docs:

    [[tool.poetry.source]]
    name = "foo_api"
    url = "https://pypi.foo.com/simple/"
    

    And it works perfectly.

    However, for uploading I had to use a different URL:

    $ poetry config repo.foo_api https://pypi.foo.com/
    $ poetry publish -r foo_api
    

    which is not what is recommended in the docs [1]

    If I use the recommendation from the Docs, then I get the following:

    Publishing foo_api (0.1.0) to mqtt_api
     - Uploading foo_api-0.1.0-py3-none-any.whl 100%
    
      UploadError
    
      HTTP Error 405: Method Not Allowed
    
      at ~/.virtualenvs/foo_api/lib/python3.10/site-packages/poetry/publishing/uploader.py:216 in _upload
          212│                     self._register(session, url)
          213│                 except HTTPError as e:
          214│                     raise UploadError(e)
          215│
        → 216│             raise UploadError(e)
          217│
          218│     def _do_upload(
          219│         self, session, url, dry_run=False
          220│     ):  # type: (requests.Session, str, Optional[bool]) -> None
    make: *** [deploy] Error 1
    

    Seems I was not the first tumbling into this issue, as I found a similar one in stackoverflow: https://stackoverflow.com/questions/65064910/cant-upload-poetry-package-to-local-dockerized-pypiserver

    Installation details Poetry version 1.1.11 Python version 3.10 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64

    Documentation Triage 
    opened by tropxy 0
  • Support PyPy 3.8

    Support PyPy 3.8

    • [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: CentOS 7.9

    • Poetry version: 1.1.11

    • Link of a Gist with the contents of your pyproject.toml file: https://gist.github.com/rodrigodc/39f71913dacf213afa5e24e8190dbe2c

    Issue

    Please update virtualenv when https://github.com/pypa/virtualenv/pull/2206 gets merged.

    Reason: virtualenvs created by Poetry are broken (not isolated) on PyPy 3.8, as described at https://github.com/pypa/virtualenv/issues/2182.

    A python3.8 dir is created in the venv (but remains empty, nothing is installed there) :point_down:

    [email protected] /tmp/test # ls <venv dir>/lib/python3.8/site-packages/
    

    A pypy3.8 symlink is created pointing to the system (global) site-packages dir (and everything is installed there) :point_down:

    [email protected] /tmp/test # ls -latr <venv dir>/lib/pypy3.8
    lrwxrwxrwx. 1 root root 28 Oct 18 18:12 <venv dir>/lib/pypy3.8 -> /usr/lib64/pypy3/lib/pypy3.8
    

    The mentioned PR fixes that.

    I can keep track of it and let you know when it gets merged and a new virtualenv version released with the fix.

    Thank you, Rodrigo

    Bug Triage 
    opened by rodrigodc 0
  • When moving a project, the hard-coded absolute interpreter path in bins break

    When moving a project, the hard-coded absolute interpreter path in bins break

    • [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
    • Poetry version: 1.1.11
    • Link of a Gist with the contents of your pyproject.toml file:

    Issue

    When using an in-project venv:

    .venv/bin/black

    #!/my/projects/project/.venv/bin/python
    # -*- coding: utf-8 -*-
    import re
    import sys
    from black import patched_main
    if __name__ == '__main__':
        sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])
        sys.exit(patched_main())
    
    

    This breaks when relocating a project.

    Not sure best approach but some suggestions here: shebang: use interpreter relative to the script path

    Maybe some kind of wrapper is needed, but this would be ugly.

    Maybe an option to allow specifying a custom interpreter script to use.

    Bug Triage 
    opened by vjpr 0
  • Poetry does not distinguish between dev and alpha versions

    Poetry does not distinguish between dev and alpha versions

    • [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 BigSur
    • Poetry version: 1.1.11

    Issue

    Hi, I have a private repository in which I have a library in both dev and alpha versions like this:

    0.1.0.dev0/		
    0.1.0.dev1/		
    0.1.0.dev2/		
    0.1.0.dev3/	
    0.1.0a1/	
    0.1.0a2/	
    0.1.0a3/
    

    Although I specify a 0.1.0a3 version (poetry add lib=='0.1.0a3') poetry always install a0.1.0.dev3 version although the 0.1.0a3 is newer. Also in pyproject.toml poetry writes that the package is in a version 0.1.0a3 although in lock.file there is a version which is actually installed 0.1.0.dev3. When I install package with pip it works correctly.

    Bug Triage 
    opened by konradkalita 2
  • removed a pitfall where the built-in name dir was being shadowed and …

    removed a pitfall where the built-in name dir was being shadowed and …

    The problem There was a built-in name shadowing pitfall on install-poetry.py where the name dir, which is a Python built-in method, was being used as a variable.;

    If for any reason the method gets called within that context, it would cause a had to detect bug because dir(arg) would not be a method being called, but a variable being called as a method.

    On top of this, the name itself was not being used for any action

    Solution Removed the name using underscore notation

    opened by NaelsonDouglas 0
  • venv created with the wrong python version

    venv created with the wrong python version

    • [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 Big Sur (11.6)

    • Poetry version: 1.1.11

    Issue

    I have both versions 3.7.2 and 3.8.0 of python installed on my mac. My .toml states the python version should be 3.7: ... [tool.poetry.dependencies] python = "~3.7" ...

    When i run "poetry update" (I use zsh terminal, don't know if it matters or not) a venv is created for my project (good), its name is myproj-DbOwq67j-py3.7 (also good), but the actual files created are python 3.8 (not good!). If you navigate to that folder you can clearly see the folder name is 3.7 but the file names are 3.8. Also I had issues installing packages that can only be installed on 3.7, so no doubt this is not just a naming issue.

    This is bad as it is, because that venv is forever broken unless I patch the poetry code that creates venvs, but even after patching I get another issue: Every time I close the terminal and reopen it, I run "poetry shell" to run commands for that venv, and i get this:

    ➜ myproj git:(master) ✗ poetry shell The currently activated Python version 3.8.0 is not supported by the project (~3.7). Trying to find and use a compatible version. Using python3 (3.7.2) The virtual environment found in /Library/Frameworks/Python.framework/Versions/3.8 seems to be broken. Recreating virtualenv myproj-DbOwq67j-py3.7 in /Users/[my user]/Library/Caches/pypoetry/virtualenvs/myproj-DbOwq67j-py3.7 Spawning shell within /Users/[my user]/Library/Caches/pypoetry/virtualenvs/myproj-DbOwq67j-py3.7 ➜ myproj git:(master) ✗ . /Users/[my user]/Library/Caches/pypoetry/virtualenvs/myproj-DbOwq67j-py3.7/bin/activate (myproj-DbOwq67j-py3.7) ➜ myproj git:(master) ✗

    Which means that the venv will be recreated once more with the wrong python version and override my patching. Also I need to reinstall all packages which in this case takes like 800s. Not fun. By the way, the version in /Library/Frameworks/Python.framework/Versions/3.8 is definitely not broken, so i don't know what that is about.

    Bug Triage 
    opened by asafalon1 1
Releases(1.1.11)
Owner
Poetry
Python packaging and dependency management made easy
Poetry
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 904 Oct 19, 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 Sep 17, 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 Oct 22, 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.4k Oct 24, 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 Oct 22, 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 Oct 2, 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 911 Oct 17, 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.5k Oct 23, 2021
A Poetry plugin for dynamically extracting the package version.

Poetry Version Plugin A Poetry plugin for dynamically extracting the package version. It can read the version from a file __init__.py with: # __init__

Sebastián Ramírez 148 Oct 9, 2021
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 500 Oct 23, 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 8 Oct 13, 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.2k Oct 22, 2021
The Fast Cross-Platform Package Manager

The Fast Cross-Platform Package Manager part of mamba-org Package Manager mamba Package Server quetz Package Builder boa mamba Mamba is a reimplementa

Mamba 2.3k Oct 24, 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 Oct 24, 2021
A flexible package manager that supports multiple versions, configurations, platforms, and compilers.

Spack Spack is a multi-platform package manager that builds and installs multiple versions and configurations of software. It works on Linux, macOS, a

Spack 2.3k Oct 15, 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 263 Oct 17, 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 262 Oct 11, 2021
A PDM plugin that packs your packages into a zipapp

pdm-packer A PDM plugin that packs your packages into a zipapp Requirements pdm-packer requires Python >=3.7 Installation If you have installed PDM wi

Frost Ming 10 Sep 23, 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 372 Aug 29, 2021