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 <konstrukt...@gmail.com>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 <justinisr...@gmail.com> 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" <fredrik.aver...@gmail.com>
>> 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 python_inside_maya+unsubscr...@googlegroups.com.
>>> 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 python_inside_maya+unsubscr...@googlegroups.com.
>> 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*
> konstrukt...@gmail.com
>
> --
> 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 python_inside_maya+unsubscr...@googlegroups.com.
> 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 python_inside_maya+unsubscr...@googlegroups.com.
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.
For more options, visit https://groups.google.com/d/optout.
