PySide, Maya, and resource file compilation at script execution

[Nico Klaassen]

Hi there everybody!

I'm currently working on improving my tool creation workflow and wanted to include images in my UI's. 

---------------------------------------------

TL,DR:

- Maya 2014

- PySide

- NOT pre-compiling ui-file, but using: pysideuic.compileUi()

- QRC (image resource) causing compilation error: 

    # Error: ImportError: file <string> line 49: No module named qrctest_qrc_rc # 

(Note: qrc-file is named; qrctest_qrc.qrc) (XML)

(Note2: The error is probably already caused from reading the implementation of a qrc resource in the ui file; qrctest_ui.ui) (XML)

----------------------------------------------

Right now I'm working with something similar to what Frederik Averpil has going on here; https://github.com/fredrikaverpil/pyVFX-boilerplate

Main difference is that I'm only focused on PySide (in combination with Maya 2014), so the 'boilerplate'-code that I'm using is a lot shorter.

Workflow is as follows; 

1) Create UI with QtDesigner

2) Copy and adept boilerplate code for the new project

3) Attach functionality to buttons etc.

4) Source in Maya & enjoy UI

This workflow breaks when I try to implement images through the resource browser (QRC-file) in QtDesigner.

Why this workflow?

By not having to pre-compile I can do fast iterations and don't have to hassle with copy-pasting compiled code. yay! Unfortunately the QRC just doesn't seem to work.

To test this, I created a small project:

-qrctest.py - http://pastebin.ubuntu.com/12306839/

-qrctest_ui.ui (XML)* - http://pastebin.ubuntu.com/12306896/

-qrctest_qrc.qrc (XML) - http://pastebin.ubuntu.com/12306884/

* There's a # at line 1 to prevent pastebin from complaining about web-stuff.

Has anybody got this working?

Kind regards,

Nico

[Marcus Ottosson]

In my experience, qrc files improve performance but little else so I generally stick with referencing plain images directly. Easy to view, modify and refactor.

Any specific reason for jumping through these hoops?

--
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_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/c6627371-a7b9-403b-b13f-fa51eaf0cef4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Marcus Ottosson
konstr...@gmail.com

[Justin Israel]

I've never used resource files without compiling them via rcc. When you use them in Designer, as you know, it will put a reference to them in your UI file. When you convert them to python via uic, it will expect the qrc to have also been compiled. I don't even know of there is a dynamic rcc operation that you can run which is similar to the uic you perform at runtime.
Maybe that boilerplate thing can be extended to suit your workflow and detect and perform the rcc at runtime before the uic happens. This would not be suitable for production, since it would be slower, and still require all the images to be present and the pathing to be correct. But it could at least suit the prototyping workflow you have chosen.

@Marcus, another benefit of compiled qrc files is that you don't have to deploy any of the source images or deal with path locations. You only need to deploy one python file as standard code in the python path.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOA-AMMHqrV_Jqq5pg3Nxtduet-6O%3Dh-U8-%3DmDG0sdZkoQ%40mail.gmail.com.

[Marcus Ottosson]

> @Marcus, another benefit of compiled qrc files is that you don't have to deploy any of the source images or deal with path locations. You only need to deploy one python file as standard code in the python path.

Yeah, but I don't buy it.

This only really makes sense if you separate between development and deployment directory. With Python, this distinction isn't made and you end up deploying the development directory. Meaning paths don't change as they do during deployment of compiled Qt.

Let's say your right, wouldn't it still mean keeping the source images in the development directory, and still deploying them? You'd end up with qrc and source images. I suppose you could selectively exclude them via some packaging mechanism like pip, but why bother?

​

[Justin Israel]

On Tue, Sep 8, 2015 at 8:11 AM Marcus Ottosson <konstr...@gmail.com> wrote:

> @Marcus, another benefit of compiled qrc files is that you don't have to deploy any of the source images or deal with path locations. You only need to deploy one python file as standard code in the python path.

Yeah, but I don't buy it.

This only really makes sense if you separate between development and deployment directory. With Python, this distinction isn't made and you end up deploying the development directory. Meaning paths don't change as they do during deployment of compiled Qt.

Why do you say this is the case? It completely depends on your deployment scheme. If you choose to deploy only the compiled resource file, then you no longer have to worry about images in a relative resource location on disk. You only have to import one python module.

 

Let's say your right, wouldn't it still mean keeping the source images in the development directory, and still deploying them? You'd end up with qrc and source images. I suppose you could selectively exclude them via some packaging mechanism like pip, but why bother?

Yes, your source images would be part of your development directory. No you don't have to deploy them if you don't want to. Deployment is something you can control. You can choose to compile UI and qrc files and only deploy the compiled ones. 

It's basically an option you have, if you see a benefit in not having to read static assets from a relative filesystem location, and also want to reduce the number of files that have to be part of your deployment.

 

​

--
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_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC_rMZZaAi-_TVuh47eFV1xDwQM83evwUU-xDnkSGbdZw%40mail.gmail.com.

[Marcus Ottosson]

Be realistic, when have you ever had to do this beyond just experimenting and learning about qrc? Yes, it's possible to make this separation and yes, somewhere there probably are those that do. But the question isn't whether it's possible, the question is why jump through these hoops?

If the OP is developing within a production environment then all the more reason to avoid qrc where deployment could be as simple as pushing to a central repo.

I'm questioning the practice of qrc in the context of Python, I think those that use it do so from reading about it in a C++ context.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA13O5GTLi8ODhE%2BPJBeMcCas35qTjkxeKv3JPuBpkM9Bg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Marcus Ottosson
konstr...@gmail.com

[Justin Israel]

On Tue, Sep 8, 2015 at 6:15 PM Marcus Ottosson <konstr...@gmail.com> wrote:

Be realistic, when have you ever had to do this beyond just experimenting and learning about qrc? Yes, it's possible to make this separation and yes, somewhere there probably are those that do. But the question isn't whether it's possible, the question is why jump through these hoops?

I do this at work... all the time. My apps make use of a converted qrc -> py. This conversion can either take place at any time, manually by a developer, and has the ability to be enforced through the build/deploy system. That means my deployed application does not have to worry about relative file paths to the application main. It just loads them from the resource system. I don't see it as hoop-jumping. It makes for a more reliable/concise deployment. And when that application has to be deployed to other locations, it doesn't matter if the source images go with it. I never have to worry if static assets will be found. 

But really, YMMV. This may not be a concern for you or the next guy.

 

If the OP is developing within a production environment then all the more reason to avoid qrc where deployment could be as simple as pushing to a central repo.

I don't want to assume what kind of deployment the OP uses. Not everyone just runs code out of a repo. For instance, in my studio deployment is the act of using a build system with rules to deploy the parts of your repo that you want, into a frozen versioned package. It doesn't matter if its Python, C++, or whatever. 

 

I'm questioning the practice of qrc in the context of Python, I think those that use it do so from reading about it in a C++ context.

Again, YMMV. It is a convenient way to embed assets into your application. It doesn't have to just be images. It can be any kind of data where you would rather "compile" it into your app and not rely on bundling it as extra assets with your deploys. 

 

Lets not make too many assumptions about what the build and deploy process means for everyone. 

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCYP06m6UB%2BSB1bVt5sueG4HiKN23iA6NWjB5iko46hcg%40mail.gmail.com.

[Marcus Ottosson]

> And when that application has to be deployed to other locations, it doesn't matter if the source images go with it.

But it does matter whether resources.py goes with it?

I don't see it. Setting up any automated system or having anyone do anything manually is hoops to me, especially when it isn't necessary. The problems of debugging a build system is greater than the problems of debugging plain files.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA028yZNyR-_V7j8-GAwHfjKx3VUw5yj%2BiJQV1G9DhdrEw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Marcus Ottosson
konstr...@gmail.com

[Justin Israel]

On Tue, Sep 8, 2015 at 7:25 PM Marcus Ottosson <konstr...@gmail.com> wrote:

> And when that application has to be deployed to other locations, it doesn't matter if the source images go with it.

But it does matter whether resources.py goes with it?

One file... that is in the same PYTHONPATH as your application source, and can't be affected by your PATH or location of the application.

 

I don't see it. Setting up any automated system or having anyone do anything manually is hoops to me, especially when it isn't necessary. The problems of debugging a build system is greater than the problems of debugging plain files.

If you don't deploy code outside of committing to a repository, then I can't expect you to understand what others whom use build tools experience. Even setuptools/distutils is a build system that can do custom deploy logic. It can use a MANIFEST with patterns/rules of what to collect and deploy. There are plenty of reasons to need build/deploy-time logic:

* documentation generation and deployment

* front end code like css/javascript that needs to be minimized

* optimized speedup extension to compile and include in the deploy

* version strings / build timestamps that need to be injected at the time of deployment

* platform-specific conditions that have to be applied. 

* unittest step that must pass before a deploy can actually go through

Fact is, there are people that use build systems, with good reason. But it's fine for you not to see it or buy it, because you obviously have not been in a circumstance where you needed any of these things. Also maybe what you consider a build system isn't the same as what I am talking about. pip (distutils/setuptools) is a build system. It takes care of lots of tasks like running tests, doing develop installs, packaging to eggs, creating source dists, and uploading to pypi. 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAoJTJpFqRyFvtCC%2BnAbC67an_DPobYEdJ4YVN%2BZVPEyQ%40mail.gmail.com.

[Marcus Ottosson]

Yes, we are probably picturing different scenarios. Not everyone works at WETA. I'd argue that most don't and what you speak of are edge-cases in the context of Python, Maya and this mailing list. Wouldn't you agree?

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3Sxz1WsF4FeCr8Jd3i7bvL3EV4gVX3L-RX%2BzS_NQWAsQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Marcus Ottosson
konstr...@gmail.com

[Justin Israel]

On Tue, 8 Sep 2015 9:16 PM Marcus Ottosson <konstr...@gmail.com> wrote:

Yes, we are probably picturing different scenarios. Not everyone works at WETA. I'd argue that most don't and what you speak of are edge-cases in the context of Python, Maya and this mailing list. Wouldn't you agree?

I don't understand what Weta has to do with this. Is it not relevant for someone to want to deploy a Maya UI tool that is as simple as two files? A main.py, and a resource.py which may contain, say 50 icons? If it made it easier for someone to just download these two files and rely only on the package being in the python path to work... isn't that valuable?

I don't see it as an edge case, or something reserved for big companies with massive deployment efforts. I just see it as a way for someone to be able to distribute a tool or library that may need a few last minute preparations.

Before Weta I was at a small studio (SouthPark), and we made heavy use of py2app to make tools available to artists and production. That is a build system.

--

Marcus Ottosson
konstr...@gmail.com

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBBLEijwy73oeGVL%2B%2By7n_1JpBPKqo_rs%2BmCF10VL3JEg%40mail.gmail.com.

[Colas Fiszman]

Hi,

I agree with Justin Build/Deployment system is not something that you can only find in big studio.

Personally i also prefer to convert the qrc to py for the same reason, i think it's more easy to import a "ressources" python module that dynamically generating the path to the images relative to the module that need them.

Greets,

Colas

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2_1pGbUjbLiEDGrRfSpN_KiLAS1jovgeFyCa7z8C26Xg%40mail.gmail.com.

[Nico Klaassen]

Thanks for the discussion everybody! I see now that I ofcourse the uic process is probably expecting the output file of pyside-rcc.

Unfortunately I won't be able to test this until later this week, but I will definitely post an update on the 'situation'.

@Marcus; I personally don't experience this workflow as 'jumping through hoops'. Instead it makes for some genuinely RAPID prototyping when it comes to changing up the UI. 

It's just that my process right now is heavily leaning on QtDesigner doing the lifting. Implementing the images in there automatically means getting involved with a qrc file. I'm not sure yet

if I would be able to just leave out the images in QtDesigner and hook 'm up to the UI that's being generated at runtime. Although I'm certainly expecting that this will be possible, it's not

the route I'm preferring to take.

Also, the deployment 

Justin wrote: Maybe that boilerplate thing can be extended to suit your workflow and detect and perform the rcc at runtime before the uic happens. This would not be suitable for production, since it would be slower, and still require all the images to be present and the pathing to be correct. But it could at least suit the prototyping workflow you have chosen.

@Justin: Yeah, ideally it would only be for prototyping. Seeing as I just recently started as a Jr. TD, I'm still trying to figure out a lot of stuff. This is one of those things. Deployment would, ideally imho, only consist of main.py + main.ui + main.qrc (in one form or another). Do I understand correctly that you always compile the ui-file and qrc-file both? (While implementing the result of the pysideuic in directly into the main.py & NOT load the UI file at runtime?)

Thanks again for everybody's time and input, really insightful!

EDIT: Sorry for the double post yesterday. This google-groups thing is very unlike other boards online.

[Marcus Ottosson]

> Instead it makes for some genuinely RAPID prototyping when it comes to changing up the UI.

Ok, I must not be understanding how you work. This is what I'm saying about *not* using qrc files. :) Agree to disagree?

[Nico Klaassen]

Let's do that haha! I think the difference lies in wanting to use a GUI (designer) or not. Directly switching things up in code, which you can refactor, can definitely be faster. Seeing that everybody else here (including you) is probably more experienced than me, I'm probably wrong though! 

Op dinsdag 8 september 2015 16:44:31 UTC+2 schreef Marcus Ottosson:

[Justin Israel]

On Wed, 9 Sep 2015 1:07 AM Nico Klaassen <klaass...@gmail.com> wrote:

...

Also, the deployment 

Justin wrote: Maybe that boilerplate thing can be extended to suit your workflow and detect and perform the rcc at runtime before the uic happens. This would not be suitable for production, since it would be slower, and still require all the images to be present and the pathing to be correct. But it could at least suit the prototyping workflow you have chosen.

@Justin: Yeah, ideally it would only be for prototyping. Seeing as I just recently started as a Jr. TD, I'm still trying to figure out a lot of stuff. This is one of those things. Deployment would, ideally imho, only consist of main.py + main.ui + main.qrc (in one form or another). Do I understand correctly that you always compile the ui-file and qrc-file both? (While implementing the result of the pysideuic in directly into the main.py & NOT load the UI file at runtime?)

Back when I *was* using Designer, my preference was always to compile ui/qrc files ahead of time, and only deploy:
main.py + main_UI.py + main_rc.py

Nowadays since I don't use designer, I just deploy python with hand written UI code, and optionally an rc python file, if I have static resources and it makes sense to do so.

Marcus, is correct that you have the option to ditch the rc and set the image paths directly in your code. And I understand that you are, at this time, choosing to do it up front in Designer so that you can have visual feedback while you design. If you do that, as we have established, you will need to convert it before runtime. If you choose to not do images in Designer, then you now have the option of whether using an rc file makes sense to you and can either use direct paths in code, or a hand written qrc.

Thanks again for everybody's time and input, really insightful!

EDIT: Sorry for the double post yesterday. This google-groups thing is very unlike other boards online.

--

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_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/752df3dd-10e8-4573-a03e-2e5cecdd2443%40googlegroups.com.