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

71–80 of 174 posts

Re: Python's New Package Landscape

#71

Post by wiremine »

another-cuppa wrote: post #69
whitehouse3 wrote: post #3

While pipenv has garnered a lot of attention and praise for ease of use, it falls over whenever I integrate it with any serious work. Pipenv lock can take 20-30 minutes on a small flask app (~18 dependencies). And it often mixes up virtualenvs, enabling the wrong one with seemingly no remedy. I see the problems on Windows, MacOS and Ubuntu. 2018 is not the year of pipenv, for me. I'm sticking with regular virtualenvs…

Pipenv is hopelessly slow. It's a shame. Remember when git first came out and it changed the way we worked because it was so quick to commit now? (I fully expect that most git users here don't remember that, actually). There is no going back. I will not use slow tools. My tools need to be at the very least as fast as me.

> Pipenv is hopelessly slow.

Interesting, this has never been a problem for me. I've built some large tools and while it isn't fast, it's always completed in a few minutes.

Re: Python's New Package Landscape

#72

Post by another-cuppa »

wiremine wrote: post #71
another-cuppa wrote: post #69

Earlier quoted context omitted.

Pipenv is hopelessly slow. It's a shame. Remember when git first came out and it changed the way we worked because it was so quick to commit now? (I fully expect that most git users here don't remember that, actually). There is no going back. I will not use slow tools. My tools need to be at the very least as fast as me.

> Pipenv is hopelessly slow. Interesting, this has never been a problem for me. I've built some large tools and while it isn't fast, it's always completed in a few minutes.

What OS?

Re: Python's New Package Landscape

#73

Post by jefurii »

patagonia wrote: post #60

Imagine I’m just getting started with Python, and I see this article. I think to myself, “Awesome, a primer!” Then I start reading (these comments)... mayyybe I should try Julia... or anything else, at least while I’m still getting started.

Just use pip and virtualenv. I've been using them on a cluster of related projects for years and they've been rock-solid.

Re: Python's New Package Landscape

#74

Post by [deleted] »

Bogdanp wrote: post #2

Having used pure pip + virtualenv{,wrapper}, pip-tools + virtualenv, poetry and Pipenv for medium to large applications, I'm going to be sticking to pip-tools for the time being for apps. Poetry is fine, but pip-tools is faster and there's less to learn. Pipenv is unbearably slow for large applications and often buggy. For libraries, I've been using Poetry for molten[1] and pure setuptools for dramatiq[2] and, at lea…

[deleted]

Re: Python's New Package Landscape

#76

Post by patagonia »

zitterbewegung wrote: post #67
patagonia wrote: post #60

Imagine I’m just getting started with Python, and I see this article. I think to myself, “Awesome, a primer!” Then I start reading (these comments)... mayyybe I should try Julia... or anything else, at least while I’m still getting started.

This isn’t a primer but more like a survey of packaging options. Using pip and virtualenv is usually fine or using pipenv .

“Usually” is great until it’s not. I don’t want to get invested in a languages only to discover issues down the line. So, if something as basic as packaging is potentially problematic and there are other options available, I might look elsewhere before rolling the dice that this problem is not too problematic.

Perhaps “Primer” was the wrong word, but I believe the sentiment is valid. Reading the comments, there is simply no consensus. If code readablility is important since code will be read more than written, packing is important because in many many scenarios that count code will be distributed more than it will be read.

It is simply frustrating that the typical response to comments like my original comment is some form of “it’s not as bad as you think”. Look, we have a problem here. A problem many other languages deem important enough to solve upfront. It’s been a problem for a long long time.

Re: Python's New Package Landscape

#77

Post by di »

toyg wrote: post #61
dlitvakb wrote: post #4

I have been using purely setuptools for all of our open source Python libraries at Contentful, but have found that lately I've been getting deprecation warnings from PyPI not to use `setup.py upload` anymore. What should the alternative be now? Edit: I'm reading about twine right now, but I cannot begin to comprehend why it's not bundled directly if this is what they are intending for us to use to upload packages.

Anything PyPI-related has recently gone into the (terrible) habit of recommending very recent (and often half-baked) tools that live entirely outside of stdlib. It seems pretty silly to me, considering Python core developers made significant efforts to bundle and support pip and virtualenv (venv) in the stdlib precisely to avoid having a lot of de-facto essential libraries outside the core distribution. If the proble…

You're mostly right, the problem is also that users don't upgrade their Python distribution very often, so they miss out on new features.

> Maybe there should be a system where specific network-sensitive stdlib modules could be updated faster than the rest.

This is essentially what `setuptools` does, by putting a package on PyPI that monkeypatches/plugs in to the stdlib.

Re: Python's New Package Landscape

#78

Post by lmm »

sambe wrote: post #55

Whenever talk in Python-world goes towards packaging, I feel like I have been transported to Javascript-world: it's never clear to me what concrete problems are being solved by the new tools/libraries. This article seems well-written and well-intentioned. Despite reading it, I don't know why I would not have loose dependencies in setup.py and concrete, pinned dependencies in requirements.txt. It's never felt hard to…

> loose dependencies in setup.py

How does that work? How would someone else coming to work on your project use them?

> concrete, pinned dependencies in requirements.txt

How do you maintain that requirements.txt? And while that might work for applications, what do you do for libraries?

Re: Python's New Package Landscape

#79

Post by iainmerrick »

wiremine wrote: post #71
another-cuppa wrote: post #69

Earlier quoted context omitted.

Pipenv is hopelessly slow. It's a shame. Remember when git first came out and it changed the way we worked because it was so quick to commit now? (I fully expect that most git users here don't remember that, actually). There is no going back. I will not use slow tools. My tools need to be at the very least as fast as me.

> Pipenv is hopelessly slow. Interesting, this has never been a problem for me. I've built some large tools and while it isn't fast, it's always completed in a few minutes.

A few minutes??! That sounds very slow.

Re: Python's New Package Landscape

#80

Post by sambe »

lmm wrote: post #78
sambe wrote: post #55

Whenever talk in Python-world goes towards packaging, I feel like I have been transported to Javascript-world: it's never clear to me what concrete problems are being solved by the new tools/libraries. This article seems well-written and well-intentioned. Despite reading it, I don't know why I would not have loose dependencies in setup.py and concrete, pinned dependencies in requirements.txt. It's never felt hard to…

> loose dependencies in setup.py How does that work? How would someone else coming to work on your project use them? > concrete, pinned dependencies in requirements.txt How do you maintain that requirements.txt? And while that might work for applications, what do you do for libraries?

I assume that someone working on the project would do:

  pip install -e .
in a virtual environment. I thought this was quite well-established. Is there a problem with it that I'm not aware of?

  pip freeze > requirements.txt
for requirements.txt generation. For libraries just omit this? I'm not sure I understand the question. The article also mentions that several of the new tools aren't appropriate for libraries anyway.
Post reply on HN