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

111–120 of 171 posts

Re: Announcing Pipenv

#111

Post by jacobmischka »

JeremyBanks wrote: post #99

> Otherwise, whatever $ which python will be the default. This is a bit strange because the python binary is always supposed to be Python 2. The Python 3 binary is supposed to be named python3. Some distributons don't follow this, but they're the weird non-conformant ones; it's not a behaviour that should really be relied on.

> always supposed to be Python 2

This is not correct. It's a symlink to python2 on systems that rely on calls to python to be python2. On modern systems, python is usually a symlink to python3. This is the case on Arch Linux and I believe other recent distro releases.

Re: Announcing Pipenv

#112

Post by georgeaf99 »

LinkedIn has a similar open source project that is much more mature. It builds on Gradle features to manage complex dependencies and build Python artifacts. If you include this LinkedIn Gradle Plugin [1] you can automatically run tests in a virtual env and source a file to enter the project's virtual env.

PyGradle [2]: "The PyGradle build system is a set of Gradle plugins that can be used to build Python artifacts"

[1] https://github.com/linkedin/pygradle/blob/01d079e2b53bf9933a...

[2] https://github.com/linkedin/pygradle

Re: Announcing Pipenv

#113

Post by snuxoll »

sametmax wrote: post #43
snuxoll wrote: post #40

Earlier quoted context omitted.

debhelper pretty much automates the process of packaging any standard distutils or setuptools package, Red Hat distributions have templates for packaging Python libraries as well (and rpmdev-newspec python-mypackage will automatically generate an appropriate .spec file). Windows and OS X are always a pain in the ass, but that's more an issue of the platforms lacking in package management than anything else.

See my point ? There is a way to do it, it's just a pain. Now pipenv centralize stuff we were doing anyway. We should have a tool to centralize those as well.

I would hardly call it a pain, it takes me all of 3 minutes to write a .spec for most python packages and from there it's basically 'tito release'. Sure, if I wanted to package for debian-based distributions it'd take a little more time, but it's worth it to make a quality package that a distribution itself can decide to pick up (packagers love other people doing the work for them, though they won't refuse doing it themselves) with minimal effort.

Re: Announcing Pipenv

#114

Post by JeremyBanks »

jacobmischka wrote: post #111
JeremyBanks wrote: post #99

> Otherwise, whatever $ which python will be the default. This is a bit strange because the python binary is always supposed to be Python 2. The Python 3 binary is supposed to be named python3. Some distributons don't follow this, but they're the weird non-conformant ones; it's not a behaviour that should really be relied on.

> always supposed to be Python 2 This is not correct. It's a symlink to python2 on systems that rely on calls to python to be python2. On modern systems, python is usually a symlink to python3. This is the case on Arch Linux and I believe other recent distro releases.

Arch is the oddball. I'm not aware of anybody else who's made the switch.

Given that they're not mutually compatible except in rare cases, it's a very silly thing to do. You can upgrade GCC with the same name because you know it will handle most of the same input. If you do that with Python you're breaking tons of existing scripts for very close to zero benefit. Why would you do that?

Re: Announcing Pipenv

#115

Post by d0mine »

sjellis wrote: post #79
renesd wrote: post #36

Earlier quoted context omitted.

I think python packaging has gotten LOTS better in the last few years. I find it quite pleasurable to use these days. From binary wheels (including on different linux architectures), to things like local caching of packages (taking LOTS of load off the main servers). To the organisation github of pypa [0], to `python -m venv` working. Also lots of work around standardising things in peps, and writing documentation fo…

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?

Re: Announcing Pipenv

#116

Post by [deleted] »

rplnt wrote: post #73
cderwin wrote: post #51

Earlier quoted context omitted.

I would look at this comment[0] by sametmax for a critique of pip. My main gripe with virtualenv is that it's required at all: other interpreted languages, like node and elixir for example, have figured out how to handle non-global dependencies without a third-party package. Beyond that, it's frustrating to deploy because its non-relocatable (in our build/deploy scripts at my last python job we had to use sed all ove…

> like node [...] have figured out how to handle non-global dependencies Node would be the last place I'd look for a good solution in. Not sure if there was some progress recently, but it was hell some time back. Modules were huge, taking thousands of other modules with them, majority of those being duplicates. There was no deduplication, no version wildcards I believe either. It wouldn't even work with some tools be…

[deleted]

Re: Announcing Pipenv

#117

Post by [deleted] »

sametmax wrote: post #56
renesd wrote: post #36

Earlier quoted context omitted.

I think python packaging has gotten LOTS better in the last few years. I find it quite pleasurable to use these days. From binary wheels (including on different linux architectures), to things like local caching of packages (taking LOTS of load off the main servers). To the organisation github of pypa [0], to `python -m venv` working. Also lots of work around standardising things in peps, and writing documentation fo…

+1. Relatively to what we have before, it's so much better. But compared to the JS/Rust ecosystem, we are behind. Now it's hard to compete with JS on some stuff : it's the only language in the most popular dev plateform (the web) and it has one implicit standardized async model by default. It's hard to compete with rust on some stuff : it's compiled and is fast, can provide stand alone binaries easily and has a check…

[deleted]

Re: Announcing Pipenv

#118

Post by HowDoesItWork »

sametmax wrote: post #56
renesd wrote: post #36

Earlier quoted context omitted.

I think python packaging has gotten LOTS better in the last few years. I find it quite pleasurable to use these days. From binary wheels (including on different linux architectures), to things like local caching of packages (taking LOTS of load off the main servers). To the organisation github of pypa [0], to `python -m venv` working. Also lots of work around standardising things in peps, and writing documentation fo…

+1. Relatively to what we have before, it's so much better. But compared to the JS/Rust ecosystem, we are behind. Now it's hard to compete with JS on some stuff : it's the only language in the most popular dev plateform (the web) and it has one implicit standardized async model by default. It's hard to compete with rust on some stuff : it's compiled and is fast, can provide stand alone binaries easily and has a check…

Wow, Javascript, really? I am guessing you don't actually work with NPM a lot.

Re: Announcing Pipenv

#119

Post by kyrias »

sametmax wrote: post #42
ghshephard wrote: post #39

Earlier quoted context omitted.

Okay - maybe I'm missing something, but pip is the only Python package manager I've ever used. And it's basically "pip install xxx", "pip install --upgrade xxx", "pip show xxx", "pip list", "pip uninstall xxx" I'm curious what I've been missing about pip that makes it problematic - I've never used the other tools you mentioned (setuptools/distutils/ez_install) - so I can't comment on them, but, on the flip side, I've…

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.…

I agree with almost all of this, but...

> - you can't easily move virtualenvs;

`virtualenv --relocatable`, though it's weird that it's not the default, yes.

Re: Announcing Pipenv

#120

Post by kyrias »

cderwin wrote: post #51
ploggingdev wrote: post #32

Earlier quoted context omitted.

Just curious, what aspects of pip/virtualenv specifically do you find subpar in comparison to other languages' package managers.

I would look at this comment[0] by sametmax for a critique of pip. My main gripe with virtualenv is that it's required at all: other interpreted languages, like node and elixir for example, have figured out how to handle non-global dependencies without a third-party package. Beyond that, it's frustrating to deploy because its non-relocatable (in our build/deploy scripts at my last python job we had to use sed all ove…

> My main gripe with virtualenv is that it's required at all: other interpreted languages, like node and elixir for example, have figured out how to handle non-global dependencies without a third-party package.

venv is in the stdlib since 3.3. (Though I agree with the annoyance at the need.)

Post reply on HN