On May 14, 2014 6:38 PM, "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? > >
This is actually my ideal situation too. Applications that are bootstrapped to pull in just the environment they and their dependencies need to launch. Two packages that have conflicting dependencies should be able to launch from the same environment. But it would be a combination of that and the current set location within a project dictating which versions of apps you should be using. Project A might be using Maya 2013 Project B might be using Maya 2014 And a specific sequence or shot within Project B might want to be testing Maya 2015 > 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. > > Technically someone could do anything they want in their setup.py so I don't think it could be said that it is always standalone. The entry point scripts it can generates can also have specific shebang lines (non Windows users) . Are you referring to any dependencies that setuptools might pull down? It doesn't package them up within the Build or anything. It just makes sure they are all there and installed to your prefix location. So if you build something that downloads 4 dependencies but you only copy off the original build elsewhere, then you would be missing those dependencies. > > 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 it >> import 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 link and here’s an example 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 . >>>> 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 . >>> >>> 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 . >> >> 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 . > > 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/CAPGFgA0_-wW_X%2BZHqYOzR9Zc9LPDTNcWk09_vHWwfCBVAyrizQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
