Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
> Guido van Rossum wrote:
>
> > Eek? If there are two third-party top-level packages A and B, by
> > different third parties, and A depends on B, how should A find B if
> > not via sys.path or something that is sufficiently equivalent as to
> > have the same problems?
>
> Some kind of configuration mechanism is needed, but
> I don't see why it can't be a static, declarative one
> rather than computed at run time.
I could be missing something, or be completely off-topic, but why not
both, or really a mechanism to define:
1. Installation time package location (register package X in the package
registry at path Y and persist across Python sessions).
2. Runtime package location (package X is in path Y, do not persist
across Python sessions).
With 1 and 2, we remove the need for .pth files, all packages to be
installed into Lib/site-packages, and sys.path manipulation. You want
access to package X?
packages.register('X', '~/mypackages/X')
packages.register('X', '~/mypackages/X', persist=True)
packages.register('X', '~/mypackages/X', systemwide=True)
This can be implemented with a fairly simple package registry, contained
within a (small) SQLite database (which is conveniently shipped in
Python 2.5). There can be a system-wide database that all users use as
a base, with a user-defined package registry (per user) where the
system-wide packages can be augmented.
With a little work, it could even be possible to define importers during
registration (filesystem, zip, database, etc.) or include a tracing
mechanism for py2exe/distutils/py2app/cx_freeze/etc. (optionally writing
to a simplified database-like file for distribution so that SQLite
doesn't need to be shipped).
- Josiah
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4