better handling of "pinned" modules?

[Andrew Jaffe]

Hi,

I don't know if this makes more sense here or on "python-ideas" (or 
elsewhere?) but I'll try this first:

I am starting to encounter more and more instances of packages requiring 
older, pinned, versions of modules, and this is occasionally actually 
starting to cause conflicts.

It seems that the "official" way to handle this is through virtual 
environments, but this is not ideal for my workflow, which usually 
involves a lot of exploratory analysis -- I don't know which packages 
I'll need before I start (and, in any event, there's no guarantee I 
won't need conflicting packages).

Are there any good workarounds, or proposals for actual solutions so 
that multiple versions of a package can be installed? I understand that 
this is not trivial. Where would the "pinning" happen? It could be in 
the source code, so that it would somehow happen in the `import` 
statement (e.g., by explicitly renaming the package in question to 
include a version number, or less likely, by a new `import` syntax)? Or 
it could happen in the structure of the way modules are stored so that, 
for example, any imports that happen within a specific package egg would 
be directed to a specific version stored within the egg or in some other 
known location?

Is this an issue worth tackling?

Or do we just have to rely on package developers to keep up with their 
dependencies?

Yours,

Andrew