some ideas, probably

gistfile1.txt

There are four places.
 1. Load site. def obj := <import:fqn.named.obj>
 2. Dependency site. fqn.named.obj => washort42@gmail.com-20130705190320-tldtfzfh5wpzuct7
 3. Requirement site. washort42@gmail.com-20130705190320-tldtfzfh5wpzuct7 => https://launchpad.net/monte
 4. Eval site. fqn.named.obj => def obj { to doStuff(...) {}}

A stdlib isn't necessary and a global scope isn't
necessary. Presumably there'll be a bootstrap scope only containing
VM-implemented prims but only scope-constructing code will run
there. Deployment means building an environment that maps some FQNs to
some code, and entry points to some code that constructs scopes for
loading further objects in.

To phrase another way: places #2 and #3 are handled by tooling that
construct some data. Place #1 invokes import, which looks at this data
to find #4.

Additionally:
Interface versions and implementation versions are separate. Interface
versioning is for describing different contracts the implementation
might provide. Implementation versioning is for describing newer or
older implementations of some interface. So for deployment you will
usually want to specify the implementation version, whereas for 
security hotfixes you'll want to upgrade to the latest version of
the implementation for that interface. In development you'll often
want to upgrade to the latest interface, of course.

I should also emphasize that this kind of versioning should extend
down to the object level, not just packages of code; no doubt tools
would keep track of which packages provided which version of which
objects but finer-grained control should be possible.


So... for development, you'd have a tool like virtualenv plus pip.

'mtenv create .' creates an empty project, perhaps with something like
E's unsafe scope already loaded.

'mtenv install foobaz' fetches the 'foobaz' package from some archive,
optionally at some specified version. It then records the url and the
unique id for the version fetched, and installs the code in the
environment under some FQN. (So if your project depends on a
'nonstandard fork', you can specify it directly.)

'mtenv link worble ~/Projects/Worble/trunk' creates an entry in our
current environment's table for an object defined in another
environment. The FQN 'worble' is mapped to the object with that name
exported by the environment in ~/Projects/Worble/trunk. This is for
development of multiple dependent projects in parallel, where one
wishes to test unreleased features in a dependency.

'mtenv export' then creates a requirements.txt-like file with FQNs,
URLs, and revision identifiers.