Brett Cannon wrote:

On 4/26/07, Adam Atlas wrote:

...

I think it would be useful for Python to accept imports of standalone files representing entire packages, maybe with the extension .pyp. A package file would basically be a ZIP file, so it would follow fairly easily from the current zipimport mechanism... its top-level directory would be the contents of a package named by the outer ZIP file. In other words, suppose we have a ZIP file called "package.pyp", and at its top level, it contains "__init__.py" and "blah.py". Anywhere this can be located, it would be equivalent to a physical directory called "package" containing those two files. So you can simply do "import package" as usual, regardless of whether it's a directory or a .pyp.

So basically zipimport, but instead of putting the zip file on sys.path the zip file exists in a directory on sys.path and the file name acts at the top-level package name? I like the idea as making stuff just work more easily by dropping into some common place and not having to muck with the import settings would be nice.

I like that too. + 1 I really dislike scattering a projects files around. And conversely, I really dislike combining files from different sources. Ron

On 30 Apr 2007, at 10.22, Christian Heimes wrote:

Adam Atlas wrote:

...

I think it would be useful for Python to accept imports of standalone files representing entire packages, maybe with the extension .pyp. A package file would basically be a ZIP file, so it would follow fairly easily from the current zipimport mechanism... its top-level directory would be the contents of a package named by the outer ZIP file. In other words, suppose we have a ZIP file called "package.pyp", and at its top level, it contains "__init__.py" and "blah.py". Anywhere this can be located, it would be equivalent to a physical directory called "package" containing those two files. So you can simply do "import package" as usual, regardless of whether it's a directory or a .pyp.

What are the benefits of your proposal over the already established Python eggs? As far as I understand your proposal it's not much different to eggs. In fact eggs + setuptools support more features like dependencies, multiversion installation and many more.

Python eggs use zipimport, which allow them to be elements of sys.path. Then, modules inside them can be imported as usual. My proposal is to make .pyp ZIP files importable themselves. You import a .pyp just like a package directory, instead of having to add an egg to sys.path and then import modules contained in it. It's convenient. It is true that eggs do have many benefits for production use, but often while developing something, or using a package that you don't expect to use outside one project, or just trying out a package that you're not sure you'll use, it's simpler to be able to just drop a file into your project directory instead of having to `sudo easy_install` it system-wide. Zero-installation is nice. Though since setuptools is set to be included in Python 2.6 (right?), maybe it could take advantage of those benefits -- perhaps .pyps could optionally include an EGG-INFO directory, and there could be a simple tool to transform those .pyps into eggs and vice versa. That way you can use whichever way is the most practical at the time, but be able to easily switch to the other if need be.