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

How To Package Your Python Code

scotttorborg.com

Post reply on HN
Print view View original

11–20 of 36 posts

Re: How To Package Your Python Code

#11

Post by borntyping »

JulianWasTaken wrote: post #2

Taking a quick look through this it looks pretty good! I find that beginners have tons of trouble navigating the slightly tricky waters that is packaging in Python, so more resources is great. One thing I think is missing is to point out not to use setuptools, but to use the less broken, more maintained, drop in replacement distribute ( http://guide.python-distribute.org/ ). That website also has some further informa…

Doesn't distribute miss out on a few of setuptools really useful features, like develop installs?

Re: How To Package Your Python Code

#12

Post by borntyping »

mixedbit wrote: post #10

Are setuptools suitable for packaging the whole web application (for example in Django) together with html/js/css files, configs for uwsgi and some management scripts? I once tried to do something like this and failed and I had an impression that setuptools are not really intended for such things, but mainly for packaging plain Python modules. Is this a right impression? If yes, what is a good way to package the whol…

It sounds like you're trying to package an entire application, not a python package. If thats the case, maintaining and distributing it may be simplest to do with a git repository.

Re: How To Package Your Python Code

#14

Post by storborg »

mixedbit wrote: post #10

Are setuptools suitable for packaging the whole web application (for example in Django) together with html/js/css files, configs for uwsgi and some management scripts? I once tried to do something like this and failed and I had an impression that setuptools are not really intended for such things, but mainly for packaging plain Python modules. Is this a right impression? If yes, what is a good way to package the whol…

Although setuptools is capable of that kind of scenario, sometimes it's not worth the overhead.

A good rule of thumb is that if you have defined access points for others to consume your code with (command line tools, Python modules, or Setuptools entry points), it's a good idea to make a Python package like this. Otherwise, skip it.

Re: How To Package Your Python Code

#15

Post by Flimm »

gvalkov wrote: post #8
borntyping wrote: post #6

Earlier quoted context omitted.

Because the only difference there is neater indentation, which you could do using the keywords method. Additionally, there's no point checking that the script is the main file, as there's only ever one use-case for the script, and that's to call setuptools.

It actually comes in handy if you're using Sphinx and don't want to maintain release and version in conf.py separately from the version in setup.py . There's no reasons why the data should be consumable only by setuptools .

You can use pkg_resources which comes with setuptools to look up the version number of your package in setup.py:

  import pkg_resources
  pkg_resources.get_distribution("PIL").version

Re: How To Package Your Python Code

#16

Post by michaelhoffman »

gvalkov wrote: post #4

I've wondered why using a dictionary to initialize setuptools.setup() isn't more advocated in such guides. I understand this is superficial, but imho, this looks much clearer than the author's suggestion [1]: from setuptools import setup kw = { 'name' : 'funniest', 'version' : '0.1', 'description' : 'The funniest joke in the world', 'url' : 'http://github.com/storborg/funniest', 'author' : 'Flying Circus', 'author_em…

Adding spaces to make things line up is proscribed by the Python Style Guide. Which is entirely optional, but many people follow it.

http://www.python.org/dev/peps/pep-0008/#pet-peeves

Re: How To Package Your Python Code

#18

Post by rhettg »

borntyping wrote: post #9
gvalkov wrote: post #8

Earlier quoted context omitted.

It actually comes in handy if you're using Sphinx and don't want to maintain release and version in conf.py separately from the version in setup.py . There's no reasons why the data should be consumable only by setuptools .

I put the version information inside the package, then anything with access to the package (which both setup.py and sphinx have) can access it - quite useful for doing things like checking the version number from the REPL, for instance.

It can be problematic to import your package from setup.py if you want your dependency specification to be useful.

Re: How To Package Your Python Code

#19

Post by shawnps »

michaelhoffman wrote: post #16
gvalkov wrote: post #4

I've wondered why using a dictionary to initialize setuptools.setup() isn't more advocated in such guides. I understand this is superficial, but imho, this looks much clearer than the author's suggestion [1]: from setuptools import setup kw = { 'name' : 'funniest', 'version' : '0.1', 'description' : 'The funniest joke in the world', 'url' : 'http://github.com/storborg/funniest', 'author' : 'Flying Circus', 'author_em…

Adding spaces to make things line up is proscribed by the Python Style Guide. Which is entirely optional, but many people follow it. http://www.python.org/dev/peps/pep-0008/#pet-peeves

I'm so glad Go removes these sort of nitpicky style problems with gofmt. At first I was bothered by how gofmt makes things line up like this, but now I prefer no style guide and a tool that formats stuff for you.
Post reply on HN