[mrkgnao]

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

[aprdm]

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.

[ben0x539]

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.

[aprdm]

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.

[mrkgnao]

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.