It takes a list of requested packages, does some dependency resolution to arrive at a matching package list, generates environment variable setting/exporting code (in Python, e.g. setting things like PYTHONPATH and MAYA_PLUGIN_PATH), then launches a new shell with that code. So, yes, you can have multiple shells with different packages in use simultaneously. I don't think it operates below the industry software package level, which makes sense, as most industry software is non-free, closed-source binaries. Each package has a `package.py` with its own list of dependencies, and code for things like manual tweaks to env vars.

>"Using Rez you can create standalone environments configured for a given set of packages. However, unlike many other package managers, packages are not installed into these standalone environments. Instead, all package versions are installed into a central repository, and standalone environments reference these existing packages. This means that configured environments are lightweight, and very fast to create, often taking just a few seconds to configure despite containing hundreds of packages."

I believe GP was asking if you could have packages A and B installed simultaneously if

  - A depended on version X of C
  - B depended on version Y of C 
  - X != Y

Yes you can because packages are not really installed at the system level. Those dependencies are all solved at runtime.

You can't have A and B in a same runtime environment obviously.

Um, just to be clear: can I write a program that depends on both A and B? Nix lets you do that.

At the same runtime? No.

At different runtimes (e.g: different package.py configurations) yes.

I can have a software called my_application which has a version that uses A and another version that uses B.

That differentiation can be a flag at runtime, a "variance" e.g: gcc-4 vs gcc-3 etc.

How does nix allow you to do that? For example, say I am using library foo and it has the function bar

In version 1

bar definition is

```

def bar(a, b):

    return a + b

```

In version 2

bar definition is

```

def bar(a):

    return a + 10

```

I don't understand how you can use v1 and v2 of foo at the same runtime? Unless nix does some namespacing based on the lib version invisibly for the enduser but that looks very prone to error...

If you release them as separated libraries it won't complain, for example, shotgun API imports can be by version

```

import shotgun3

import shotgun2

```

so theoretically you can release a rez package whose name is shotgun3 and another one whose name is shotgun2.

That way you would effectively have shotgun2 and shotgun3 in a same runtime environment.

I wasn't really thinking about language-level runtimes, like, I don't want to solve the problem of only having one global scope in python and running into module name collisions. I'm not sure how concerned rez is with shell environments beyond what (eg.) python packages are available in it, but I was wondering about having a shell where a program foo is available that, say, requires a lib compiled with gcc-4, and another program bar that requires the same lib at the same version but compiled with gcc-3.

Nix expends a bunch of complexity into fucking with dynamic linking to make that work transparently most of the time and deploying wrapper scripts to cover other cases, so I was curious if rez has a cleverer solution there.

Oh yeah, it is certainly possible.

you have build_requires which you can list dependencies that you require at build time (e.g: gcc-3 vs gcc-4) but not at runtime.

So you can have things that were built with gcc-3 and gcc-4 running side by side in a same shell environment without issues.

gcc itself, in this case, would be a rez package that can have multiple versions installed in the system.

Essentially, Nix treats every version of a package, or every "instance" of a package compiled with different flags, or different "build inputs", as a completely different dependency. So foo-1.0, foo-2.0, and foo-2.0-debug are all separate things you can depend on, from the POV of the package manager. A huge "symphony" (a friend's term) of symlinks holds it all together.