[aprdm]

By reading your comment and a little bit of the package declarations in some nix packages, it seems like the software package system of nix is very similar to rez.

Rez ( https://github.com/nerdvegas/rez ) is used by some visual effects companies (including mine) to manage software packages.

It allows us to have great flexibility in the mix & match of software versions and runtime environments.

[wmertens]

Cool! Indeed, Rez does something similar on the package management side.

For Nix, this is almost a side-effect, however. Nix's primary task is to describe how to build packages, and the entire OS is just another package that groups all dependencies. You can make a single change to a file everything depends on and it will result in a new OS.

Nix can evaluate the entire system configuration in seconds, and build or download missing binaries in parallel.

As a result you can e.g. have a complete OS based on a different glibc (maybe with some patch you like) installed and running alongside the normal OS without the glibc patch. Packages that do not use glibc are simply shared.

[ben0x539]

Does rez handle having an environment with two apps in it that require differing versions of the same dependency?

[gfixler]

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."

[mrkgnao]

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

[aprdm]

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.

[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.