[HN Gopher] I moved away from Poetry for Python
___________________________________________________________________
I moved away from Poetry for Python
Author : todsacerdoti
Score : 10 points
Date : 2022-12-15 20:25 UTC (2 hours ago)
(HTM) web link (usrme.xyz)
(TXT) w3m dump (usrme.xyz)
| mattbillenstein wrote:
| Been using pip-tools for years - it seems to just solve the
| problem in a clean and simple way.
|
| How did Poetry get so much momentum vs pip-tools and pipenv?
| a9h74j wrote:
| I wish they had named it Pyetry instead of Poetry.
| pantojax45 wrote:
| Main thing I want is lock files. I want to know exactly when full
| dependency closure changes and to see diffs when it does (and be
| able to reproduce why closure changed). Otherwise you get weird
| issues with packages updating when not expected. I was surprised
| linked James Bennett post didn't mention that at all.
|
| I've liked poetry in general, just takes a really long time and
| sometimes its solver gets stuck on a bad package.
| cpburns2009 wrote:
| This doesn't look good for the future of Poetry. Its maintainers
| are acting as obstinate as pipenv's. I guess I'll be sticking to
| pip-tools.
| masenf wrote:
| I recently developed a tox plug-in, tox-pin-deps [1], that
| integrates the pip-compile workflow with dependencies specified
| in tox.ini (per environment). This was in response to both poetry
| and Pipenv being non-standard and consistent stumbling blocks for
| ramping up new devs on the team.
|
| Despite the shiny, I seem to always find my way back to standard
| tools and text files.
|
| [1]: https://github.com/masenf/tox-pin-deps
| PaulHoule wrote:
| Before I found poetry I worked at a place that had python
| projects that were too complicated for pip to download
| dependencies for. I had developed a tool that, for our projects,
| could build a set of wheels to deploy a project. I had thought
| about what a general solution would look like but before
| implementing anything I found poetry.
|
| Poetry struck me as one of those 80% solutions that might get in
| the way of a 100% solution. I used it for a number of little
| projects and felt it was good enough but my analysis was that its
| dependency resolution strategy was pretty slow and that I didn't
| believe it was 100% correct.
|
| For my own Python projects I've been really slumming it lately. I
| make venv's with pycharm and let pycharm manage my dependencies.
| I also have written a number of "single file Python" programs
| that I use on my Linux server to do things like burn DTS CD-Rs
| with complete CD-Text information. For those ones I just stick to
| the standard library. One of these days I'm going to have to
| deploy a real python project to a server and I'll have to think
| of something then.
|
| I convinced myself that the right way to resolve dependencies in
| Python is to do the same thing maven does and form a graph of the
| dependencies of all the software versions that could possibly
| satisfy the constraints.
|
| For wheel files it is practical to do because you can download
| the metadata in 2 or 3 http range requests out of a wheel. eggs
| are a problem because you are expected to download and run the
| python scripts inside the egg before you know anything about the
| egg. fortunately (1) wheels have mostly replaced eggs and (2) you
| can build wheels as to the needs of your organization in a
| private "wheelhouse" used for builds in your organization.
|
| Since it takes a long time to fetch that information it really
| does have to have a local cache like maven and maybe even a
| metadata database. It would be nice to see python build cleaned
| up.
| jujube3 wrote:
| _One of these days I 'm going to have to deploy a real python
| project to a server and I'll have to think of something then._
|
| That's the point at which you rewrite it in go
___________________________________________________________________
(page generated 2022-12-15 23:02 UTC)