4 ms·

I've spent the last couple of weeks experimenting with converting some work-related modules to use Poetry, and although I immediately loved a few of the improve

I've spent the last couple of weeks experimenting with converting some work-related modules to use Poetry, and although I immediately loved a few of the improvements, there are a few drawbacks that weren't immediately obvious. Chiefly, the inability of the combination of poetry and pip to create editable installs of a module is a drag. Using "poetry shell" is ok, but many of the users of the module I maintain are accustomed to using pipenv or plain old virtualenvs and I'm as loathe to try to induce them to use some other tool for this as I would be if the tables were turned. The other more serious issue is that the modules I take care of are internal things in a private PyPI repository, and poetry unfortunately has a few bugs in this area. Working fixes are in PRs that have been sitting for months, and I've attempted to contact what I think is the project maintainer without any response. In my opinion, that's absolutely fine; this is a volunteer effort, I certainly don't expect the volunteers to do heroics to support me, and I can come up with some way of getting the patches that I need into the tool. But at the same time, the ideal tool for dealing with Python packaging is going to need to be able to coordinate this sort of stuff with the pip maintainers, and to have some mechanism to support corporate users and all that boring stuff. I want to be enthusiastic about this one because it definitely seems to knock off a lot of sharp corners in python packaging, but I'm not sure if its got legs.

neolog 6y ago
`poetry install` installs the current project in editable mode.
- gooseyard 6y ago
  it does, but most of the users of this module are accustomed to being able to run "pip install -e ." in order to get the module editable in their virtualenv, and since this module has dependencies that are also in the private repo, the issues that I alluded to (which affect private repos using artifactory which require client certs) cause trouble. I'm still optimistic that these things will get fixed, but it's not going as smoothly as I'd hoped.
  - Caligatio 6y ago
    I actually wrote the client cert code back in the day, what problems are you having?
    - gooseyard 6y ago
      When a cert is specified for a repo, the solver will use the cert and ca list when querying for packages, but after solving won't pass the cert and verify values when constructing the requests session to download the packages. There's a fix in https://github.com/python-poetry/poetry/pull/3490 https://github.com/python-poetry/poetry/pull/3490, but it has been pending review for several months. There's a second issue (this one isn't cert related) where repos that return a 403 when a given package doesn't exist causes the solver to abort, which is problematic if your private repo is Artifactory, since the solver interprets this as an auth misconfiguration and won't fall back to the primary repo. Based on some comments in the threads for those PRs I wondered if maybe the delay in merging was that some changes to the way repositories are configured, but it'd be great to have a temporary workaround for the time being.
the_jeremy 6y ago
Exactly my problem. Poetry 1.1.0 through 1.1.4 (aka every release since Jul 2020) are broken on our private PyPI instance. If you maintain OSS python packages, poetry might be great for you, but it's apparent the maintainers aren't willing to support enterprise use, and I wish that was made clear to potential users.

neolog 6y ago

`poetry install` installs the current project in editable mode.

gooseyard 6y ago
it does, but most of the users of this module are accustomed to being able to run "pip install -e ." in order to get the module editable in their virtualenv, and since this module has dependencies that are also in the private repo, the issues that I alluded to (which affect private repos using artifactory which require client certs) cause trouble. I'm still optimistic that these things will get fixed, but it's not going as smoothly as I'd hoped.
- Caligatio 6y ago
  I actually wrote the client cert code back in the day, what problems are you having?
  - gooseyard 6y ago
    When a cert is specified for a repo, the solver will use the cert and ca list when querying for packages, but after solving won't pass the cert and verify values when constructing the requests session to download the packages. There's a fix in https://github.com/python-poetry/poetry/pull/3490 https://github.com/python-poetry/poetry/pull/3490, but it has been pending review for several months. There's a second issue (this one isn't cert related) where repos that return a 403 when a given package doesn't exist causes the solver to abort, which is problematic if your private repo is Artifactory, since the solver interprets this as an auth misconfiguration and won't fall back to the primary repo. Based on some comments in the threads for those PRs I wondered if maybe the delay in merging was that some changes to the way repositories are configured, but it'd be great to have a temporary workaround for the time being.

the_jeremy 6y ago

Exactly my problem. Poetry 1.1.0 through 1.1.4 (aka every release since Jul 2020) are broken on our private PyPI instance. If you maintain OSS python packages, poetry might be great for you, but it's apparent the maintainers aren't willing to support enterprise use, and I wish that was made clear to potential users.