Thanks everyone for this invaluable input! :) // Fredrik
On Wed, May 14, 2014 at 3:19 PM, Marcus Ottosson <konstrukt...@gmail.com>wrote: > I made a write-up about context sensitivity in projects/assets/shots > recently - with pros and cons and a simple reference implementation, from > the point of view of the shell. > > *Terminal Context Sensitivity <http://rfc.abstractfactory.io/spec/57/>* > > Maybe it could help. > > Best, > Marcus > > > On 14 May 2014 14:01, Tony Barbieri <great...@gmail.com> wrote: > >> I highly recommend developing your launcher to take into account the >> project context. Even if you aren't technically using that functionality >> in the beginning, having the users first set their project context then >> launching the appropriate application with it's dependencies could save you >> a lot of headaches in the future. We haven't gone as granular as having >> sub project contexts such as sequence/shot/asset (at least at launch time, >> once in the app we do), but we have the ability to set that up in the >> future if necessary. >> >> >> On Wed, May 14, 2014 at 5:18 AM, Justin Israel <justinisr...@gmail.com>wrote: >> >>> >>> On May 14, 2014 6:38 PM, "Fredrik Averpil" <fredrik.aver...@gmail.com> >>> 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 < >>> 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 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 <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 >>> . >>> >>>> 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 >>> . >>> >>> >>> >>> 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 >>> . >>> >> >>> >> 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. >>> >>> -- >>> 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/CAPGFgA0_-wW_X%2BZHqYOzR9Zc9LPDTNcWk09_vHWwfCBVAyrizQ%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0_-wW_X%2BZHqYOzR9Zc9LPDTNcWk09_vHWwfCBVAyrizQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> -tony >> >> -- >> 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/CAJhmvsT8ZejEMrn%2B%3DribTzPESGu%2BTKFB2U%3DRLZ3wa-REpFvNkQ%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAJhmvsT8ZejEMrn%2B%3DribTzPESGu%2BTKFB2U%3DRLZ3wa-REpFvNkQ%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/CAFRtmODGgtRP0Be3nOwHG7FOee7GFYP%2BSK3GaQNOFvHdQnCk-w%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODGgtRP0Be3nOwHG7FOee7GFYP%2BSK3GaQNOFvHdQnCk-w%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%3DwhWM-epTH314hrTymVoOSXD8ZGOZD97Pwwg_BUj00ddupXQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
