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

151–160 of 171 posts

Re: Announcing Pipenv

#151

Post by [deleted] »

sametmax wrote: post #149
snuxoll wrote: post #135

Earlier quoted context omitted.

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…

[deleted]

Re: Announcing Pipenv

#152

Post by snuxoll »

sametmax wrote: post #149
snuxoll wrote: post #135

Earlier quoted context omitted.

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…

Making a typical python package for Fedora or EL:

Do you have a setup.py? No, then it's not going to be on PyPi anyway so ignore the rest of this since you'll need to figure out how to package this special snowflake.

0. Run `yum install -y rpmdevtools mock`

1. Run `rpmdev-newspec python-mypackage`.

2. Run `python setup.py sdist`

3. Modify the .spec as appropriate to add dependencies the package requires as well as set the version correctly.

4. Run `mock -r fedora-25-x86_64 --buildsprm python-mypackage.spec`

5. Run `mock -r fedora-25-x86_64 --rebuild python-mypackage.f25.src.rpm`

Done, there's your RPM, debian packaging is roughly as simple (I'm less a fan because of how they try to fudge a Makefile into an adequate tool for package building, but hey, most everything can be built automatically by dh so the average makefile is ~3 lines).

The biggest problem with learning this is simply finding the right documentation, Fedora has some pretty great guides for new packagers on the wiki.

Re: Announcing Pipenv

#153

Post by sjellis »

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?

Python best practice: figure out the correct directory structure by reading docs and looking at GitHub repositories, learn how to write setup.py & setup.cfg & requirements.txt & MANIFEST.in files, setup py.test and tox (because Python 2 still lives), write your README in RST format (as used by nothing else ever), and for bonus points: write your own Makefile. Get depressed when you realize that target platforms either don't have Python or have the wrong version.

Rust: type "cargo new", README and doc comments in Markdown, type "cargo test" and "cargo build".

I'm being deliberately snarky, but you get the point: there has been a slow accretion of complexity over a very long time, and most of it is not the language itself.

Re: Announcing Pipenv

#154

Post by jacobmischka »

JeremyBanks wrote: post #114
jacobmischka wrote: post #111

Earlier quoted context omitted.

> 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?

It's not silly. One of Arch's primary draws is being the first to get updates and integrate new technologies. Other distros will follow soon enough if there really aren't any others.

It's not as if python2 suddenly doesn't exist, it's not terribly life-changing to add a 2 in the places where the scripts are still on the last version.

I'm glad to be on a system where the default Python version isn't one that will be officially unsupported in three years.

Edit: It's worth pointing out that this switch was made 6 years ago and the world is still spinning.

https://www.archlinux.org/news/python-is-now-python-3/

Re: Announcing Pipenv

#155

Post by brennebeck »

cderwin wrote: post #126
brennebeck wrote: post #67

Earlier quoted context omitted.

> Also notable, IMO, is the lack of a tool like rbenv or rustup for python Does pyenv not meet your needs there?

Oh cool, I actually hadn't seen pyenv before. Looks like it does indeed solve my problems (from a glance anyway, though I didn't see anything about pip in the readme).

`pyenv which pip` would be the command that answers the specific point you mentioned :). That also works for any bin that gets shimmed by pyenv.

It also has plugins to automatically work with venv, if you don't mind some 'magic' in your workflow.

Overall it's a solid setup.

Re: Announcing Pipenv

#156

Post by mkesper »

kyrias wrote: post #119
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.…

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.

Note: you must run this after you've installed any packages into the environment. If you make an environment relocatable, then install a new package, you must run virtualenv --relocatable again

Re: Announcing Pipenv

#157

Post by sametmax »

dvl wrote: post #134

Why people are trying to complicate things? requirements.txt are much simpler and better.

First, you need to take care of the virtualenv manually. This tool avoid that. You can completly ignore the virtualenv. You don't even have to populate requirements or learn about pip freeze.

Secondly, this tool allow you to freeze your requirement list at specific versions. So in your req file, you have the name of the packages you depend on. Bon on the req lock, you get all the pulled dependencies recursively with the version you are using right now. The first one let you dev more easily. The second one deploy more easily.

All that, for less complexity. Win win.

Re: Announcing Pipenv

#158

Post by Diederich »

sametmax wrote: post #148
Diederich wrote: post #143

Earlier quoted context omitted.

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.

That makes sense.

That's been the default behaviour of Perl package managers for a long, long time now.

Re: Announcing Pipenv

#159

Post by JeremyBanks »

jacobmischka wrote: post #154
JeremyBanks wrote: post #114

Earlier quoted context omitted.

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?

It's not silly. One of Arch's primary draws is being the first to get updates and integrate new technologies. Other distros will follow soon enough if there really aren't any others. It's not as if python2 suddenly doesn't exist, it's not terribly life-changing to add a 2 in the places where the scripts are still on the last version. I'm glad to be on a system where the default Python version isn't one that will be o…

They can adopt Python 3 and drop Python 2 without adding this link which encourages a convention of /usr/bin/env python for Python 3 on their platform, creating unnecessary incompatibility with other platforms.

As you said, it's old news now, and not the end of the world. But I'm hoping others don't follow.

Re: Announcing Pipenv

#160

Post by nerdwaller »

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…

I'd strongly disagree with Python being behind relative to JS. They're roughly on par (with Python being slightly ahead due to smarter caching and more deterministic builds). Unfortunately neither does namespacing nor good versioning, especially in the cache. Take for example Maven (from Java), it caches namespaced and versioned dependencies and is pretty reliably deterministic in the build process.

Verses node which makes horribly assumptions that allow dependencies of libraries to be resolved and dumped into the same library namespace as your application. It also allows users to use the shrinkwrap feature, which imposes the dependency's settings on me (say, for example, I want to use my own npmjs proxy, this is bypassed...)

Post reply on HN