Ingy's talk was "the Python Package package package, 'package'". In
other words, it's a package for packaging packages, called Package. He
started with some general rants about Python distribution:
- The core does not include a downloader-installer or dependency
handler. People have to install Setuptools (and/or Distribute, Pip,
and Virtualenv) manually. This is a major stumbling block for newbies,
especially when it doesn't work the first time.
- Python has "one way to do it" in the core, but "more than one way to
do it" outside. Setuptools or Distribute? Unittest or Nose or py.test?
This puts a burden on both package developers and users, especially
because developers can't count on users having third-party packages
installed, and the installation may fail when they do install them.
- All top-level Python packages have to have unique names across all
of Pythonia. As opposed to Java and Perl where you can distribute a
sovereign package under a hierarchy, such as "com.amazon.foo" or
"HTML::Ingy".
He introduced Package and led a group exercise of creating a package
with Package and uploading it to PyPI. The exercise didn't go too
well because people had trouble installing Git on Mac and Windows, and
Package behaved unexpectedly on some platforms. So it turned out to be
a usability session, which is also good, because it allows problems to
be fixed before a large number of people are using the package.
To create a package, you download Package but don't install it.
Instead you create a project directory and run "make -f
../package-py/Makefile setup". This creates setup.py and other
infrastructure files. You then modify a YAML file (which is basically
a superset of setup.py options) and run "make package-info", which
generates the egg-info and other files. (setup.py calls a Package
function, which parses the YAML file and runs the usual command).
"make register" creates a PyPI entry for your package, and "make
upload" uploads it. The package includes your code, and I think it
includes a copy of Package and Setuptools and a test framework, which
factors out all of the packaging hassles for the developer.
(I didn't quite see how it works for the user. Supposedly the user
would be able to install your package with just one command. But how
can they do that without first installing Setuptools, or downloading
and installing the package manually?)
Some of the problems revolve around vague vocabulary in the Python
world, and even more inconsistent vocabulary between programming
languages. So here are a few working definitions.
A Python MODULE is a "*.py" file, which is normally located under
sys.path so that it can be imported. A Python script does not have to
follow these conventions. You execute scripts by filename: "python
a/b/myscript". You execute modules with the -m switch: "python -m
myapp.scripts.foo", which translates to myapp/scripts/foo.py . The
difference is significant for the Python path and for importing
application modules. With -m, the current directory is put on
sys.path, and so "myapp" and any sibling packages are importable.
Without -m, the script's parent directory ("b") is put on sys.path,
and so anything under "b" will appear to be top-level, and anything
above "b" will not be importable. If "myscript" is actually a module
within a package, this throws off the imports because the top-level
packages are not what was intended. If you install a package first,
into site-packages or a virtualenv, then it can be imported no matter
what the current directory or script location is.
A Python PACKAGE is a directory under sys.path, which contains an
__init__.py module and perhaps other modules, and may recursively
contain similar directories ("subpackages").
A Python DISTRIBUTION is a source tarball or Python Egg, which may be
uploaded to PyPI. Confusingly, people also call distributions
"packages". This usually doesn't matter, but it does when you're
talking about distributions and packages in the same sentence.
PyPI is the central catalog of distributions. It contains metadata
about the distribution, and optionally source tarballs, eggs, a link
to the distribution website, and/or a link to the source repository
(usually BitBucket nowadays, but also Google, SourceForge, GitHub,
etc).
--
Mike Orr <[email protected]>
