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

Twisted History of Python Packaging

speakerdeck.com

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Twisted History of Python Packaging

#11

Post by batgaijin »

kennywinker wrote: post #10

I'm a relative newcomer to python. I've been successfully using pip, and more recently pip+virtualenv to install packages. There haven't been many speedbumps so far, though I'm not hitting the system that hard. I do miss the "Gemfile" type of abstraction that Ruby or CocoaPods provides. That said, the other day I tried to figure out how to package a bit of code I wanted to make reusable. It was a complete clusterf k.…

well, since python is so much more readable than ruby you can just hand out a .py :P

I usually write python and just moved to ruby, and as much as I like python I don't think anyone brings DSLs into the conversation as much as it should be.

Re: Twisted History of Python Packaging

#12

Post by ianb »

kennywinker wrote: post #10

I'm a relative newcomer to python. I've been successfully using pip, and more recently pip+virtualenv to install packages. There haven't been many speedbumps so far, though I'm not hitting the system that hard. I do miss the "Gemfile" type of abstraction that Ruby or CocoaPods provides. That said, the other day I tried to figure out how to package a bit of code I wanted to make reusable. It was a complete clusterf k.…

If you have a "simple" package, i.e., Python-only, and no namespace fanciness, find a setup.py from a package you use, copy it, scan and rewrite it, and you are probably good to go.

Just avoid:

- Namespace packages. This is where you have one package that provides, say, mypackageset.thing1, and another package that provides mypackageset.thing2. If you really want to have a "brand" with many packages in it, just name it mypackageset_thing1 and save yourself a headache.

- If you have important non-.py files (e.g., templates) in your package, you'll have to learn package_data (http://docs.python.org/2/distutils/setupscript.html#installi...) and maybe MANIFEST.in. These are annoying, and you won't notice when you install from a checkout or with "pip install -e". You might need to study up more on this thing in particular (or just poke around until it works).

- Some people use requirements.txt instead of install_requires inside setup.py now. I often use both – but with install_requires just for the absolute minimum of what might be required.

Re: Twisted History of Python Packaging

#13

Post by kennywinker »

batgaijin wrote: post #11
kennywinker wrote: post #10

I'm a relative newcomer to python. I've been successfully using pip, and more recently pip+virtualenv to install packages. There haven't been many speedbumps so far, though I'm not hitting the system that hard. I do miss the "Gemfile" type of abstraction that Ruby or CocoaPods provides. That said, the other day I tried to figure out how to package a bit of code I wanted to make reusable. It was a complete clusterf k.…

well, since python is so much more readable than ruby you can just hand out a .py :P I usually write python and just moved to ruby, and as much as I like python I don't think anyone brings DSLs into the conversation as much as it should be.

The whole advantage of packaging is `pip install mypackage`, which you don't get with a raw .py. and my module has a couple of non-.py resources contained.

I really really really really really really hate DSLs. That's part of why I like Python more than Ruby. I want to learn one consistent language, not dozens of magic keywords that apply only in certain situations. I recognize that there is a place for them, it's just that in my mind that place is called "Ruby". ;)

Re: Twisted History of Python Packaging

#14

Post by pyre »

chimeracoder wrote: post #9

It's hard to tell with just the slides (and no talk), but it seems like this isn't presenting the complete/correct picture. Pip can use distribute or setuptools - it's not exactly an alternative as slide 31 makes it seem from just the text. On a higher level, while it's interesting to know the evolution that things have taken, it's really not that complicated anymore - I haven't run into issues with Python packaging…

  >  it's really not that complicated anymore
Depends on your use-case. I wasn't at the talk (and haven't watched the video, yet), but apparently there was a bit of a 'heated' debate during the question portion of the talk. Apparently some people from the scientific Python community have given up waiting for their issues to be addressed and are working on their own packaging solution to meet their needs.

If most of your modules are pure-Python or maybe a little bit of C, then you might not be running into the warts that the current packaging systems have.

Also, running 'pip install package' hides what kind of lengths that developers/package maintainers have to go through to get things working correctly. That's also part of the discussion when talking about a decent packaging system.

  > I often miss the virtualenv + pip approach
Perl's "perlbrew + cpanm" approach is more fully featured. I miss having a 'requirements.txt' type capability, but perlbrew downloads/compiles Perl, so each environment can have a different version of Perl, which is a little more complex with virtualenv.

Re: Twisted History of Python Packaging

#15

Post by recursive »

programminggeek wrote: post #7

Python's not awesome packaging back in the easy_install days really put me off of using django as much as I could have. I liked python a lot, but I ended up in ruby more because gems were a much nicer way to go and bundler made it nice. Good to see python catching up a bit in that regard, but I enjoy ruby and Sinatra too much to switch back at this point.

So what exactly is the problem with easy_install? I just recently discovered it and it seems quite nice to me.

Re: Twisted History of Python Packaging

#16

Post by programminggeek »

recursive wrote: post #15
programminggeek wrote: post #7

Python's not awesome packaging back in the easy_install days really put me off of using django as much as I could have. I liked python a lot, but I ended up in ruby more because gems were a much nicer way to go and bundler made it nice. Good to see python catching up a bit in that regard, but I enjoy ruby and Sinatra too much to switch back at this point.

So what exactly is the problem with easy_install? I just recently discovered it and it seems quite nice to me.

Package discovery was annoying. With Ruby, gems, and bundler I can define my project gems and install them with 'bundle install'. Any machine I move to it does that. It's fantastic.

With node and npm you can do more or less the same thing.

Maybe with easy_install you can now, but I remember having to manually download packages and easy_install them. No package management, no easy discovery, no project dependency management.

Post reply on HN