Thank you for that thorough explanation. You suggested loading packages
based on project. I’m thinking I’d be better off here to load packages
based on software config.
You’re welcome. :) And yes, that certainly makes sense. How about this:
$ /root/metadata.json
{
'maya': {
'PYTHONPATH': '/root/maya/scripts'
},
'nuke': {
'PYTHONPATH': '/root/nuke/scripts'
}
}
Something you could then cascade, perhaps on a per-project basis, should
you need it:
$ /projects/hulk/metadata.json
$ /projects/spiderman/metadata.json
$ /projects/lotr/metadata.json
And viola, you’ve got metadata on a per-project, per software basis.
You could even do:
# Custom environment setup, for a single user on a single shot within
a single project
$ /projects/hulk/shots/1000/private/marcus/metadata.json
And finally, for individual versions of software:
$ /root/metadata.json
{
'maya-2014x64': {
'PYTHONPATH': '/root/cool/scripts'
},
'maya-2009x86': {
'PYTHONPATH': '/root/less-cool/scripts'
}
}
However, .json and others can get quite large and or messy when taken to
this extreme. Which is another reason I need openmetadata. :)
Hope it helps.
ps. I’m a markdown fanatic and found this plugin for Chrome,
<http://markdown-here.com/>http://markdown-here.com/
On 14 May 2014 07:37, Fredrik Averpil <[email protected]> wrote:
> Hi Marcus,
>
> Thank you for that thorough explanation. You suggested loading packages *based
> on project*. I'm thinking I'd be better off here to load packages based
> on software config. Also, I have a question regarding installing and
> building packages (how can I know that they are completely standalone?)...
>
>
> *Loading packages based on software config*
>
> Here in our studio, I'm building a software launcher which essentially
> generates environment variables and launches the appropriate executable. I
> think that for me it would make more sense to generate the PYTHONPATH based
> on which combo of selections users are making in the app launcher. For
> example, they may be choosing to launch Maya 2014 with V-Ray 2.45 (of a
> certain nightly build) and some other plugin. We don't use environment
> paths to specify a shot or a sequence, so for as long a user has the app
> opened, the environment variables generated apply for that app.
>
> What do you guys think about such an approach?
>
>
> *Installing and building packages - are they standalone?*
>
> Also, since I'm new to pip and setuptools, I'm just wondering... when I
> perform a pip install --target //server/share/package... into a certain
> directory, I've been having troubles confirming that this package is now
> completely standalone and can be imported from any other machine of the
> same type without anything but a local python installation. But this seems
> to be the case. Am I correct?
> Also, for some package's source (downloaded from e.g. github/google code),
> I've been using setuptools to build the project: python setup.py build
> (avoiding
> eggs)
> Then I manually move the built project into a certain location. Again, I'm
> assuming the package built is completely standalone. This is right, right?
> When "pip installing" or "setuptools building" packages, I'm doing that
> from my Win7 64-bit machine and from a virtual CentOS 6.4 64-bit machine
> (with a virtualenv with --no-site-packages). Seems to work nicely. If you
> have any pointers to give me here, as I'm new to this, I would appreciate
> that very much.
>
>
>
> I'm truly thankful for all your fantastic input, guys. If you end up
> visiting siggraph this year I definitively owe you a beer or two :)
> This mailing list is invaluable!
>
>
> Regards,
> Fredrik
>
> PS. Marcus, what are you using to get such nice code formatting in your
> emails? :)
>
>
>
> On Wed, May 14, 2014 at 7:50 AM, Marcus Ottosson
> <[email protected]>wrote:
>
>> My addition to this topic would be a similar approach to Justin’s. Host
>> packages individually and modify PYTHONPATH based on your criteria, such as
>> project. Each project could then define their own paths, pointing to their
>> relevant versions of their relevant packages.
>>
>> /hulk/scripts/pakA/__init__.py
>> /hulk/scripts/pakB/1.4.7/pakB/__init__.py
>> /hulk/scripts/pakB/1.4.8/pakB/__init__.py
>> /hulk/metadata.json --> {'PYTHONPATH': 'scripts/:scripts/pakB/1.4.7'}
>>
>> And then, it could also be useful, in cases where you’d like per-shot or
>> per-asset overrides of your PYTHONPATH, to get metadata to cascade.
>>
>> /hulk/metadata.json
>> /hulk/shots/1000/metadata.json --> {'PYTHONPATH': '../../scripts/pakB/1.4.8'}
>>
>> Here, shot 1000 introduces additional dependencies which would be added
>> to the initial /hulk/metadata.json. At this point, you can establish a
>> foundation metadata container at the root of each project (or all projects)
>> and override essentials as you go.
>>
>> You could roll your own cascade mechanism, or you could have a look at a
>> library I'm working on called openmetadata;
>>
>> # This would be the gist of itimport openmetadata as om
>> location = om.Location('/hulk/shots/1000')
>> pythonpath = om.Entry('PYTHONPATH', parent=location)
>> om.inherit(pythonpath)print
>> pythonpath'/projects/hulk/scripts/:/projects/hulk/scripts/pakB/1.4.8'
>>
>> Here is a github <https://github.com/abstractfactory/openmetadata> link
>> and here’s an
>> example<https://github.com/abstractfactory/openmetadata/blob/master/openmetadata/examples/inheritance.py>on
>> how to set up the metadata for inheritance.
>>
>> Best,
>> Marcus
>>
>>
>> On 13 May 2014 09:30, Justin Israel <[email protected]> wrote:
>>
>>> We manage versions with a custom packaging and deploy system that is
>>> integrated with the environment management system. The eggs can be annoying
>>> because they require being reliant on either having pth files being updated
>>> or having the eggs added to the path as opposed to just a normal package.
>>> I think if you have the versions and packaging managed externally then
>>> the eggs are superfluous.
>>> On May 13, 2014 7:52 PM, "Fredrik Averpil" <[email protected]>
>>> wrote:
>>>
>>>> Thanks guys for all your input. How come you don't use eggs?
>>>> I thought eggs with egg-infos were supposed to be the easy way to
>>>> maintain versions and distribute modules?
>>>>
>>>> Fredrik
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Python Programming for Autodesk Maya" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWMxKgHOat0ua%2BO4msn21Xc2BBXpOg46Ytdx-zXi4Bj-XQ%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWMxKgHOat0ua%2BO4msn21Xc2BBXpOg46Ytdx-zXi4Bj-XQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Python Programming for Autodesk Maya" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0jiVCH1hQ8%3DyURDL9vtcOwkkSVkmOsAbpLHseyFVJ_RA%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0jiVCH1hQ8%3DyURDL9vtcOwkkSVkmOsAbpLHseyFVJ_RA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> *Marcus Ottosson*
>> [email protected]
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Python Programming for Autodesk Maya" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAuk5Y7KmpXkLPZnkpjrXi0ceZqp%3DMuVfswQ1HYv745OQ%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAuk5Y7KmpXkLPZnkpjrXi0ceZqp%3DMuVfswQ1HYv745OQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWN4PCxu%3DjvME%2BOnPmKUsUh27COdV23Hx%3DHP-0tMJ6rApg%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWN4PCxu%3DjvME%2BOnPmKUsUh27COdV23Hx%3DHP-0tMJ6rApg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
*Marcus Ottosson*
[email protected]
--
You received this message because you are subscribed to the Google Groups
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBp1wkCd5xgqOJKfVJWmrwxSQTd1M188C70DK8a5OYD%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
