I've had my eyes on this since it got shot across the interwebs and thought it looked interesting, but wasn't in a position to make use of it at the time. Is this still in development? Also, what are your thoughts on Rez as an alternative?

Thanks

Hi,

This is happening with the develop branch and I'm probably not understanding some of the stuff. I have created two simple files for tests as follows:

ocio_configuration.env

{
    'tool': 'ocio_configuration',
    'version': '',
    'platforms': ['windows'],
    'requires': [],
    'environment':
        {
        'OCIO': {'windows': 'D:\OCIO\config.ocio'},
    }
}

nuke_10_0.env

{
    'tool': 'nuke',
    'version': '10.0',
    'platforms': ['windows'],
    'requires': ['ocio_configuration'],
    'environment':
        {
        'NUKE_MAJOR_VERSION': '10.0',
        'NUKE_MINOR_VERSION': '5',
        'NUKE': {'windows': 'C:/Program Files/Nuke${NUKE_MAJOR_VERSION}v${NUKE_MINOR_VERSION}', },
        'NUKE_VERSION': 'Nuke${NUKE_MAJOR_VERSION}v${NUKE_MINOR_VERSION}',
        'NUKEX_VERSION': 'NukeX${NUKE_MAJOR_VERSION}v${NUKE_MINOR_VERSION}',
        'PATH': {'windows': '${NUKE}'},
    },
}

So my initial basic assumption would be that a command such as:

eco -r nuke10.0

Would run Nuke but unfortunately I get an error:

'nuke10.0' is not recognized as an internal or external command,
operable program or batch file.

I need to add the requirement as per the documentation to actually have it launching:

eco -t nuke10.0 -r nuke10.0

Except if I missed something obvious it seems to defeat the purpose of dependency solving, which leads me to the next train of issues:

I took a look at the environment being injected before launching Nuke and I noticed that the ocio_configuration requires seem to be ignored because the variable is set to my original system defined value, thus I have to add manually the requirement which is again defeating dependency solving:

eco -t nuke10.0,ocio_configuration -r nuke10.0

Which in turns resulted of concatenation of the system variable plus the one defined in the ocio_configuration.env file:

Warning - invalid OpenColorIO config file D:/OCIO/config.ocio;D:/Tools/OCIO/config.ocio specified by OCIO environment variable!
OCIO features will be unavailable for this session.

Something I don't get is why the environment doesn't start blank but inherits the system and user variables? If I print os.environ just before call_process, I have a fat list of environment variables which are exactly the ones defined in the system and my user profile, plus the Ecosystem ones. My expectations in that regard were like this by the way ;)

Bests,

Thomas

Hi on the first line of : https://github.com/PeregrineLabs/Ecosystem/blob/master/bin/ecosystem.py
you are using :

!/usr/bin/python

where it should be better using :

!/usr/bin/env python

in this way custom python build and installation will be working fine.

Hi!

This might be a stupid question, but after cloning the repo and runing pip install ecosystem I'm getting this error:

Collecting ecosystem
Could not find a version that satisfies the requirement ecosystem (from versions: )
No matching distribution found for ecosystem

This is on Windows 10. What's the advantage of this new installation system anyway? Everything used to work fine when I was simply cloning the repo and setting some environment variables....

It seems that this project is stalled currently. Additionally many people use rez which is very actively developed. Any opinions?

When I run the alias or manually the python command I get this:

$ eneed maya2016
-bash: /tmp/ecoset: line 1: syntax error near unexpected token `('
-bash: /tmp/ecoset: line 1: `Unable to resolve all of the required tools (!:1 is missing), please check your list and try again!'
/usr/local/Ecosystem
$ ecosystem.py --setenv --tools maya2016 > /tmp/ecoset; source /tmp/ecoset
-bash: setenv: command not found
-bash: setenv: command not found
-bash: setenv: command not found
-bash: setenv: command not found

Looks like the argument parsing doesn't work with bash shell which is the default on OSX. Which also explains why setenv is not working. Also I really doubt that the whole system will work since it relies on LD and DYLD_LIBRARY_PATH which is disabled since El Capitan.