Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python's New Package Landscape

andrewsforge.com

Post reply on HN
Print view View original

111–120 of 174 posts

Re: Python's New Package Landscape

#111

Post by epage »

blattimwind wrote: post #38
epage wrote: post #37

The biggest problem I have with python packaging tools is how do I start using them. I'd rather not install all of them in my global site-packages. Do I need to create a virtualenv just to get a tool to manage my virtualenv's? I have seen poetry is working on their bootstrapping story. I could not get their current solution to work on Ubuntu. Maybe what they are developing towards will work. https://github.com/sdispa…

pip install --user

Doesn't that just install into a global-to-the-user path? Isn't one of the things we're trying to avoid is conflicts between these tools. For example, pip is now more freely breaking compatibility. I now need to ensure if my different packaging tools are compatible with my version of pip all installed in my user location.

Re: Python's New Package Landscape

#112

Post by philosopherlawr »

andybak wrote: post #43

In case this scares any new users, I've used nothing more than pip and virtualenv for several years with no issues of note.

There are lots of errors when it comes to reproducing the build on other machines. Pip install -r requirements.txt does not guarantee that you will install the same version of packages on a new machine, and in fact, you will typically not.

Re: Python's New Package Landscape

#114

Post by _x5tx »

cik wrote: post #94

We just went through this cycle - ultimately we build packages (debs) and dockers, for deployment within VMs. Our build process - depending on the component pushes the deb to repos, or uses the deb in the docker. After trying to replace pip with Pipenv, we had to stop. The dependency resolution time for 20 declared dependencies (that in turn pull down > 100 components) takes well over 5 minutes. With poetry - it take…

I did have the same problem, and apart from taking too long for dependency resolution it felt like breaking up at each update, sometimes from pipenv update, sometimes from pip update making pipenv breaking. I migrated to poetry and never been happier.

Re: Python's New Package Landscape

#117

Post by edmorley »

cik wrote: post #94

We just went through this cycle - ultimately we build packages (debs) and dockers, for deployment within VMs. Our build process - depending on the component pushes the deb to repos, or uses the deb in the docker. After trying to replace pip with Pipenv, we had to stop. The dependency resolution time for 20 declared dependencies (that in turn pull down > 100 components) takes well over 5 minutes. With poetry - it take…

I was about to rule out Poetry due to pyup not supporting it, however it turns out Dependabot (which as a bonus looks to be more actively maintained than pyup) supports it:

https://dependabot.com/blog/announcing-poetry-support/

Re: Python's New Package Landscape

#118

Post by peterkelly »

andybak wrote: post #43

In case this scares any new users, I've used nothing more than pip and virtualenv for several years with no issues of note.

Seconded. I read this article and thought "nope, not touching any of those tools". I'd rather spend my time building products than spending a week researching the landscape of 10 different package management approaches.

Re: Python's New Package Landscape

#119

Post by Serow225 »

xapata wrote: post #101
Serow225 wrote: post #81

Earlier quoted context omitted.

Does anyone know why the Python community has seemed to struggle with package mgmt fragmentation/churn so much over the years, compared to other languages? Did Guido just not really care about package mgmt?

Guido wrote Python in 1990. Did you use a package manager back then? I didn't. Part of the issue is how well Python integrates with non-Python dependencies. Before conda, when I wanted to upgrade some Python projects, I'd get errors complaining about my Fortran compiler. These days, most of the major projects upload precompiled binaries for major platforms to PyPI, but when it was just source code...

Sure, but couldn't it have been given some BFDL/high-level leadership importance in the last five years to rein in the craziness?

Re: Python's New Package Landscape

#120

Post by di »

1wd wrote: post #86
di wrote: post #70

Earlier quoted context omitted.

Hello, I'm the person who deprecated `setup.py upload`. The warnings should be telling you that `twine` is the preferred tool for uploading. The reason for this is that right now, that command comes from `distutils`, which is part of the standard library. There is a huge disadvantage to bundling this functionality with your Python distribution, namely that it can only get upgraded when you upgrade your Python distrib…

Why not bundle twine like pip? In fact, why not merge the twine functionality into pip?

> Why not bundle twine like pip?

The `pip` package is not actually bundled with your Python distribution, instead the standard library has `ensurepip` which provides a means of bootstrapping a `pip` installation without `pip` itself. See [0].

> In fact, why not merge the twine functionality into pip?

This has been considered and still might happen, see [1], specifically the comment at [2].

[0] https://docs.python.org/3/library/ensurepip.html

[1] https://github.com/pypa/packaging-problems/issues/60

[2] https://github.com/pypa/packaging-problems/issues/60#issueco...

Post reply on HN