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

Announcing Pipenv

kennethreitz.org

Post reply on HN
Print view View original

141–150 of 171 posts

Re: Announcing Pipenv

#141

Post by barbs »

cderwin wrote: post #24

This is great, but sometimes I think that python needs a new package manager from scratch instead of more tools trying to mix and mash a bunch of flawed tools together in a way that's palatable by most of us. Python packaging sucks, the whole lot of it. Maybe I'm just spoiled by rust and elixir, but setuptools, distutils, pip, ez_install, all of it is really subpar. But of course everything uses pypi and pip now, so…

All you've said here is "python packaging sucks", with no explanation why, and with no alternative. Not a substantial comment, and I'm disappointed that it's been voted to the top.

I'd ask for your reasoning but it seems sametmax has done a good job of that for you:

https://news.ycombinator.com/item?id=13460490

Re: Announcing Pipenv

#142

Post by bastawhiz »

d0mine wrote: post #115
sjellis wrote: post #79

Earlier quoted context omitted.

This is actually one of the big problems, I think: Python packaging involves knowing a number of different things and reading various resources to get the full picture. Recently, I built a small CLI tool in Python, and learned all of the bits needed to build, test and package my application "the right way". I knew Python syntax before, but it was a lot of effort to set this up. The difference in the experience betwee…

Could you provide some specific examples of the "shocking" difference?

`setup.py` is shockingly awful compared to most other solutions.

Re: Announcing Pipenv

#143

Post by Diederich »

sametmax wrote: post #110
Diederich wrote: post #92

Earlier quoted context omitted.

Honest question: have you seen how the Perl world handles this stuff? Now that I've mostly moved over to Python, the Perl experience (overall package mgmt) seems much, much better. Note, it doesn't feel terrible in Python land, to me at least. But it was almost a joy working with Perl's packaging system.

No. Does it build a dependency graph and output your the best path to upgrades ?

It does build a dependency graph...But I'm not sure what you mean by 'best' path to upgrade.

Re: Announcing Pipenv

#144

Post by jessaustin »

barbs wrote: post #141
cderwin wrote: post #24

This is great, but sometimes I think that python needs a new package manager from scratch instead of more tools trying to mix and mash a bunch of flawed tools together in a way that's palatable by most of us. Python packaging sucks, the whole lot of it. Maybe I'm just spoiled by rust and elixir, but setuptools, distutils, pip, ez_install, all of it is really subpar. But of course everything uses pypi and pip now, so…

All you've said here is "python packaging sucks", with no explanation why, and with no alternative. Not a substantial comment, and I'm disappointed that it's been voted to the top. I'd ask for your reasoning but it seems sametmax has done a good job of that for you: https://news.ycombinator.com/item?id=13460490

Comments that make a single unambiguous point are fine. It's no problem to leave detailed support to replies.

A more controversial statement with the same content probably wouldn't have been voted up, but thread parent is objectively true even though it doesn't contain its own proof.

Re: Announcing Pipenv

#145

Post by StavrosK »

AgentME wrote: post #123
StavrosK wrote: post #96

Earlier quoted context omitted.

How can you have an upper bound on compatibility? When a library is released, it knows that it works with version 1.3.2 with its dependency, but how can it ever know it doesn't work with 1.4, unless the developer goes back and re-releases the app?

If the library follows semantic versioning, then you can always declare that you work with everything from the current version to before the next major version.

That's what I usually do (although I pin minor, because you never know). I should also be better about following semver, but it just feels wrong to have your library be at version 5.43.55 :/

Re: Announcing Pipenv

#147

Post by mdeeks »

schlumpf wrote: post #55
sametmax wrote: post #42

Earlier quoted context omitted.

One things is a good dependency management. Right now if you want to upgrade your Python version, or one of your packages, it's a mountain of manual work. There is nothing in the stack helping you with the dependency graph. Another thing is providing a stand alone build. Something you can just ship without asking the client to run commands in the terminal to make it work. I use nuikta ( http://nuitka.net/ ) for this.…

This. Particularly the need for a minimum standard project structure. Pipenv shows its pedigree and looks like a great tool...that also overlaps significantly with conda. What are the use cases that Pipenv addresses better than/in lieu of conda?

It looks like Pipenv does not handle the python install itself or associated non-python libraries. With Conda I can tell it to install Python 3.6 along with FreeTDS (for mssql). Conda lets me do this in one environment.yml file and have it work cross platform. Separate homebrew or apt-get steps are no longer necessary.

That said pipenv still looks awesome. Any improvement to the python packaging world is welcome gift.

Re: Announcing Pipenv

#148

Post by sametmax »

Diederich wrote: post #143
sametmax wrote: post #110

Earlier quoted context omitted.

No. Does it build a dependency graph and output your the best path to upgrades ?

It does build a dependency graph...But I'm not sure what you mean by 'best' path to upgrade.

Choosing the combination of the most up to date compatible lib versions, or tell you can't update and let you know the conflict source.

Re: Announcing Pipenv

#149

Post by sametmax »

snuxoll wrote: post #135
sametmax wrote: post #129

Earlier quoted context omitted.

3 minutes because you know how.

And it took me all of 60 minutes to learn, packaging isn't anywhere near as hard as people make it out to be. If you can use a build system of your choosing to build and test your project, you can learn how to write an rpmspec or debian control file in under an hour.

It took me months to learn the best practices to create a clean Python package. And nothing is particularly difficult. Just information to gather and sort out. Given deb/rpm are old systems with a lot of legacy, I seriously doubt your 60 minutes claim, even if it's infinity better than Python status quo. Which I doubt as well since all GNU standard are usually a spaghetti of past requirements mixed with FOSS politics.
Post reply on HN