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. A while ago I wrote a program called Squisher that does this (it takes a ZIP file and turns it into an importable .pyc file), but it's a huge hack. The hackishness mainly comes from my desire to not require users of Squished packages to install Squisher itself; so each module basically has to bootstrap itself, adding its own import hook and then adding its own path to sys.path and shuffling around a couple of things in sys.modules. All that could be avoided if this were a core feature; I expect a straightforward import hook would suffice. As PEP 302 says, "Distributing lots of source or pyc files around is not always appropriate, so there is a frequent desire to package all needed modules in a single file." It's very useful to be able to download a single file, plop it into a directory, and immediately be able to import it like any .py or .pyc file. Eggs are nice, but having to manually add them to sys.path or install them system-wide with setuptools is not always ideal.
On 4/26/07, Adam Atlas <adam@atlas.st> 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. -Brett
Brett Cannon wrote:
On 4/26/07, Adam Atlas <adam@atlas.st> 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
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. Christian
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.
On Monday 30 April 2007, Adam Atlas wrote:
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.
-1 on adding yet-another-ZIP-thing. Python eggs aren't always convenient, but they're easy enough to work with, and good tools to work with egg-based installations are appearing. Having another way to do this, especially something that will be turned into eggs for deployment, seems like a distraction. Differences between development environments and production environments lead to bugs, not ease-of-use. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
participants (5)
-
Adam Atlas -
Brett Cannon -
Christian Heimes -
Fred L. Drake, Jr. -
Ron Adam