Thanks to everyone who came out last night. I'd like to apologize for not having things "on rails". ;) Things could have been smoother, but I think there was a lot of good energy in the room. I look forward to joining the seapig ranks on a regular basis.
Mike's assessment of "package" is spot on. I think it is valuable effort but is currently lacking in stability, documentation and ease of use. I intend to fix all three areas. Anybody who wants to help out, please let me know. When "package" reaches the next step of goodness, I'll point you all at the docs, and ask you to try it out again and give me another round of feedback. Mike, on a side note, can you point me at a URL that talks about the "DISTRIBUTION" nomenclature in Python? I haven't seen it in my Python research. We also call tarballs, "distributions" in Perl/CPAN land. Cheers, Ingy On Fri, May 14, 2010 at 1:16 PM, Mike Orr <[email protected]> wrote: > 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]> >
