Julian Martinz Posted November 5, 2019 Report Share Posted November 5, 2019 Is there an option to revert a location to default after setting it up to be unmanaged with the ftrack_api.mixin() method? I have to publish components to the same location during a session. Some of them are already where they belong so I want to add them through the unmanaged location. For others (especially those created by the official plugins // publishers) I'd like to rely on the default behaviour. - Julian Link to comment Share on other sites More sharing options...
Lorenzo Angeli Posted November 7, 2019 Report Share Posted November 7, 2019 Hi @Julian Martinz if you want to use either one or the other in the same project you might have to think of creating what I would call a proxy location. This location would accept both (or more) the locations you want to use and through logical gates you can redirect the publish to what you want, either based on task, component or any other logic that suits you. Hope it helps. L. Link to comment Share on other sites More sharing options...
Julian Martinz Posted November 7, 2019 Author Report Share Posted November 7, 2019 Hey Lorenzo, thanks for the reply. I think @JPrydz mentioned that concept before. You don't happen to have a code example ready? Or at least a draft or a hint? After a short glance at the location class I'd start by overriding/extending the add_component method and implement the logic there. Does that sound sensible? Best, Julian Link to comment Share on other sites More sharing options...
Lorenzo Angeli Posted November 8, 2019 Report Share Posted November 8, 2019 Hi @Julian Martinz , we'll be looking soon on providing something off the shelf. Your approach seems the on the right track though ! L. Link to comment Share on other sites More sharing options...
Julian Martinz Posted November 15, 2019 Author Report Share Posted November 15, 2019 Hey @Lorenzo Angeli, looking forward to your example. In the meantime I tried it myself and got a working version up n running. Unfortunately it doesn't really help me with the original problem. I can configure my proxy location to choose between distinct locations with different names like studio.server1 and studio.server2 (which is great btw and helps me solve some other issues I had). However, to choose between a managed and unmanaged version of the same location I'd have to create both instances beforehand, which afaik is not possible as they are essentially the same? Or at least I don't know how. What would work is creating two distinct locations studio.server1 and studio.server1.unmanaged. But that's not really what I am after. And that brings me back to my original question: Is there any way to revert a location instance back to the state it was before mixin in the unmangedLocationMixin? The only solution I can think of right now would be to reconfigure my locations by emitting an 'ftrack.api.session.configure-location' event. But that doesn't seem right .. - Julian Link to comment Share on other sites More sharing options...
Lorenzo Angeli Posted November 19, 2019 Report Share Posted November 19, 2019 >> What would work is creating two distinct locations studio.server1 and studio.server1.unmanaged. Hi Julian, my suggestion of having a third location acting as proxy was coming from the idea of leveraging two different location with different behaviour. This though , requires to have clear rules on how these two locations will accept data (eg: image sequences -> unamanged, maya files-> managed.) >> Is there any way to revert a location instance back to the state it was before mixin in the unmangedLocationMixin? Not that I'm aware of tbh.... the above solution was though to be able to provide both at the same time. >> reconfigure my locations by emitting an 'ftrack.api.session.configure-location' event. This is something should be called when initialising the session not sure doing it programmatically would provide the results you are after. L. Link to comment Share on other sites More sharing options...
Julian Martinz Posted November 19, 2019 Author Report Share Posted November 19, 2019 Hey Lorenzo, Quote Hi Julian, my suggestion of having a third location acting as proxy was coming from the idea of leveraging two different location with different behaviour.This though , requires to have clear rules on how these two locations will accept data (eg: image sequences -> unamanged, maya files-> managed.) > Is there any way to revert a location instance back to the state it was before mixin in the unmangedLocationMixin? Not that I'm aware of tbh.... the above solution was though to be able to provide both at the same time. That's absolutely fine .. but how can I create these two locations with the same name but different behaviour? When trying to create to locations with the same name the session will logically throw an error. Or are you talking about two entirely different location? To stick to my example: studio.server1.managed and studio.server1.unmanaged? If so that's actually not what I am after. The point is that I only want to differentiate on publish/component-creation. Once the components are published, you shouldn't be able to distinguish between components added via the unmanaged or via the managed location. So basically just as if you are adding components to a configured location or the same location after mixin in the unmanagedLocation mixin. Once added there is essentially no difference between the components. But maybe that's just not possible? Or maybe I am missing the point. Best, Julian Link to comment Share on other sites More sharing options...
Lorenzo Angeli Posted November 20, 2019 Report Share Posted November 20, 2019 Hi @Julian Martinz, you cannot create two locations with the same name that would confuse the system. The idea of the proxy is exactly for this reason, the proxy will have your old name to match (studio.server1), where the underlying (proxied) locations will retain the different behaviour (studio.server1.managed, studio.server1.unmanaged) and the logic in the overwritten methods of the proxy location will dictate what component to handle with what location. Hope it helps. L. Link to comment Share on other sites More sharing options...
Julian Martinz Posted November 21, 2019 Author Report Share Posted November 21, 2019 hey @Lorenzo Angeli Okay think I got it. I thought of the proxy location as a mere "switch" that forwards the add_component method to one of the two locations and then the component is addaed to the actual location (server1.managed/server1.unmanaged). But what you are proposing is to actually add the component to the proxy-location and just leveraging the methods from the other (configured) locations. Did I get it? Best Julian Link to comment Share on other sites More sharing options...
Lorenzo Angeli Posted November 22, 2019 Report Share Posted November 22, 2019 Hi @Julian Martinz looks like we are on the same page now let us know how it goes! L. Link to comment Share on other sites More sharing options...
Chandler Posted December 17, 2019 Report Share Posted December 17, 2019 Hey @Lorenzo Angeli could you clarify where the most up-to-date boilerplate code of your proxy solution is right now? I've seen you post it before, but I don't see a link in this thread, and this is all I can find now:http://docs.efestolab.uk/tools/proxy-location/index.html I'd like to explore implementing this on our end. Link to comment Share on other sites More sharing options...
Lorenzo Angeli Posted December 19, 2019 Report Share Posted December 19, 2019 Hi @Chandler there no boilerplate at the moment, but I'll try to find time new year to come up with one. As you find out though, there was one once, and is the one I'll try to bring back to life or close to what that was at least. Hope it helps. L. Chandler 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now