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

171–174 of 174 posts

Re: Python's New Package Landscape

#171

Post by mixmastamyk »

epage wrote: post #111
blattimwind wrote: post #38

Earlier quoted context omitted.

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.

Yes, and that's fine for most folks. The one exception I make is developing a huge app at work, use a virtualenv for that to keep it separate.

Re: Python's New Package Landscape

#172

Post by mixmastamyk »

di wrote: post #70
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.

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…

What if you are already on Py3.6, don't need markdown-descriptions (not sure what that is btw), and been happily using setup.py upload for a decade?

Re: Python's New Package Landscape

#173

Post by web007 »

kankroc wrote: post #47
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…

Can you elaborate on why using a requirements.txt file is "manual hell"? I rely on it for pretty much everything and I didn't run into game breaking problems.

The problem requirements.txt doesn't solve is "what I want" versus "what I end up with".

There's no concept of explicit versus implicit dependencies. You install one package, and end up with five dependencies locked at exact versions when you do `pip freeze`. Which of those was the one you installed, and which ones are just dependencies-of-dependencies?

If you're consistent and ALWAYS update your requirements.txt first with explicit versions and NEVER use `pip freeze` you might be okay, but it's more painful than most of the alternatives that let you separate those concepts.

Re: Python's New Package Landscape

#174

Post by cmcginty »

guitarbill wrote: post #121
kankroc wrote: post #47

Earlier quoted context omitted.

Can you elaborate on why using a requirements.txt file is "manual hell"? I rely on it for pretty much everything and I didn't run into game breaking problems.

because if you pin stuff in requirements.txt, they either never get updated, or you have to go through, check which ones have updated, and manually edit the requirements.txt. the combination of Pipfile and Pipfile.lock were designed to solve this in a much better way (briefly: understanding standard deps vs development deps, and using the Pipfile.lock file for exact pinning/deployment pinning, vs general compatibilit…

Or just use pip-tools to automatically update dependency versions.
Post reply on HN