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! Op dinsdag 8 september 2015 11:37:28 UTC+2 schreef colas: > > 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 > > 2015-09-08 10:27 GMT+01:00 Justin Israel <[email protected] > <javascript:>>: > >> >> On Tue, 8 Sep 2015 9:16 PM Marcus Ottosson <[email protected] >> <javascript:>> 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. >> >> >> >> On 8 September 2015 at 09:57, Justin Israel <[email protected] >> <javascript:>> wrote: >> >> On Tue, Sep 8, 2015 at 7:25 PM Marcus Ottosson <[email protected] >> <javascript:>> 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. >> >> >> >> >> On 8 September 2015 at 07:33, Justin Israel <[email protected] >> <javascript:>> wrote: >> >> On Tue, Sep 8, 2015 at 6:15 PM Marcus Ottosson <[email protected] >> <javascript:>> 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. >> >> >> On 7 September 2015 at 22:15, Justin Israel <[email protected] >> <javascript:>> wrote: >> >> On Tue, Sep 8, 2015 at 8:11 AM Marcus Ottosson <[email protected] >> <javascript:>> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC_rMZZaAi-_TVuh47eFV1xDwQM83evwUU-xDnkSGbdZw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC_rMZZaAi-_TVuh47eFV1xDwQM83evwUU-xDnkSGbdZw%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 [email protected] <javascript:>. >> >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA13O5GTLi8ODhE%2BPJBeMcCas35qTjkxeKv3JPuBpkM9Bg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA13O5GTLi8ODhE%2BPJBeMcCas35qTjkxeKv3JPuBpkM9Bg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> >> *Marcus Ottosson* >> [email protected] <javascript:> >> >> -- >> 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] <javascript:>. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCYP06m6UB%2BSB1bVt5sueG4HiKN23iA6NWjB5iko46hcg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCYP06m6UB%2BSB1bVt5sueG4HiKN23iA6NWjB5iko46hcg%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 [email protected] <javascript:>. >> >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA028yZNyR-_V7j8-GAwHfjKx3VUw5yj%2BiJQV1G9DhdrEw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA028yZNyR-_V7j8-GAwHfjKx3VUw5yj%2BiJQV1G9DhdrEw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> >> *Marcus Ottosson* >> [email protected] <javascript:> >> >> -- >> 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] <javascript:>. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAoJTJpFqRyFvtCC%2BnAbC67an_DPobYEdJ4YVN%2BZVPEyQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAoJTJpFqRyFvtCC%2BnAbC67an_DPobYEdJ4YVN%2BZVPEyQ%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 [email protected] <javascript:>. >> >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3Sxz1WsF4FeCr8Jd3i7bvL3EV4gVX3L-RX%2BzS_NQWAsQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3Sxz1WsF4FeCr8Jd3i7bvL3EV4gVX3L-RX%2BzS_NQWAsQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> >> *Marcus Ottosson* >> [email protected] <javascript:> >> >> -- >> 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] <javascript:>. >> 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 >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBBLEijwy73oeGVL%2B%2By7n_1JpBPKqo_rs%2BmCF10VL3JEg%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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2_1pGbUjbLiEDGrRfSpN_KiLAS1jovgeFyCa7z8C26Xg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2_1pGbUjbLiEDGrRfSpN_KiLAS1jovgeFyCa7z8C26Xg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > Op dinsdag 8 september 2015 11:37:28 UTC+2 schreef colas: > > 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 > > 2015-09-08 10:27 GMT+01:00 Justin Israel <[email protected] > <javascript:>>: > >> >> On Tue, 8 Sep 2015 9:16 PM Marcus Ottosson <[email protected] >> <javascript:>> 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. >> >> >> >> On 8 September 2015 at 09:57, Justin Israel <[email protected] >> <javascript:>> wrote: >> >> On Tue, Sep 8, 2015 at 7:25 PM Marcus Ottosson <[email protected] >> <javascript:>> 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. >> >> >> >> >> On 8 September 2015 at 07:33, Justin Israel <[email protected] >> <javascript:>> wrote: >> >> On Tue, Sep 8, 2015 at 6:15 PM Marcus Ottosson <[email protected] >> <javascript:>> 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. >> >> >> On 7 September 2015 at 22:15, Justin Israel <[email protected] >> <javascript:>> wrote: >> >> On Tue, Sep 8, 2015 at 8:11 AM Marcus Ottosson <[email protected] >> <javascript:>> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC_rMZZaAi-_TVuh47eFV1xDwQM83evwUU-xDnkSGbdZw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC_rMZZaAi-_TVuh47eFV1xDwQM83evwUU-xDnkSGbdZw%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 [email protected] <javascript:>. >> >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA13O5GTLi8ODhE%2BPJBeMcCas35qTjkxeKv3JPuBpkM9Bg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA13O5GTLi8ODhE%2BPJBeMcCas35qTjkxeKv3JPuBpkM9Bg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> >> *Marcus Ottosson* >> [email protected] <javascript:> >> >> -- >> 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] <javascript:>. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCYP06m6UB%2BSB1bVt5sueG4HiKN23iA6NWjB5iko46hcg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCYP06m6UB%2BSB1bVt5sueG4HiKN23iA6NWjB5iko46hcg%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 [email protected] <javascript:>. >> >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA028yZNyR-_V7j8-GAwHfjKx3VUw5yj%2BiJQV1G9DhdrEw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA028yZNyR-_V7j8-GAwHfjKx3VUw5yj%2BiJQV1G9DhdrEw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> >> *Marcus Ottosson* >> [email protected] <javascript:> >> >> -- >> 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] <javascript:>. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAoJTJpFqRyFvtCC%2BnAbC67an_DPobYEdJ4YVN%2BZVPEyQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAoJTJpFqRyFvtCC%2BnAbC67an_DPobYEdJ4YVN%2BZVPEyQ%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 [email protected] <javascript:>. >> >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3Sxz1WsF4FeCr8Jd3i7bvL3EV4gVX3L-RX%2BzS_NQWAsQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3Sxz1WsF4FeCr8Jd3i7bvL3EV4gVX3L-RX%2BzS_NQWAsQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> >> *Marcus Ottosson* >> [email protected] <javascript:> >> >> -- >> 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] <javascript:>. >> 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 >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBBLEijwy73oeGVL%2B%2By7n_1JpBPKqo_rs%2BmCF10VL3JEg%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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2_1pGbUjbLiEDGrRfSpN_KiLAS1jovgeFyCa7z8C26Xg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2_1pGbUjbLiEDGrRfSpN_KiLAS1jovgeFyCa7z8C26Xg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > Op dinsdag 8 september 2015 11:37:28 UTC+2 schreef colas: > > 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 > > 2015-09-08 10:27 GMT+01:00 Justin Israel <[email protected] > <javascript:>>: > >> >> On Tue, 8 Sep 2015 9:16 PM Marcus Ottosson <[email protected] >> <javascript:>> 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. >> >> >> >> On 8 September 2015 at 09:57, Justin Israel <[email protected] >> <javascript:>> wrote: >> >> On Tue, Sep 8, 2015 at 7:25 PM Marcus Ottosson <[email protected] >> <javascript:>> 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. >> >> >> >> >> On 8 September 2015 at 07:33, Justin Israel <[email protected] >> <javascript:>> wrote: >> >> On Tue, Sep 8, 2015 at 6:15 PM Marcus Ottosson <[email protected] >> <javascript:>> 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. >> >> >> On 7 September 2015 at 22:15, Justin Israel <[email protected] >> <javascript:>> wrote: >> >> On Tue, Sep 8, 2015 at 8:11 AM Marcus Ottosson <[email protected] >> <javascript:>> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC_rMZZaAi-_TVuh47eFV1xDwQM83evwUU-xDnkSGbdZw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC_rMZZaAi-_TVuh47eFV1xDwQM83evwUU-xDnkSGbdZw%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 [email protected] <javascript:>. >> >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA13O5GTLi8ODhE%2BPJBeMcCas35qTjkxeKv3JPuBpkM9Bg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA13O5GTLi8ODhE%2BPJBeMcCas35qTjkxeKv3JPuBpkM9Bg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> >> *Marcus Ottosson* >> [email protected] <javascript:> >> >> -- >> 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] <javascript:>. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCYP06m6UB%2BSB1bVt5sueG4HiKN23iA6NWjB5iko46hcg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCYP06m6UB%2BSB1bVt5sueG4HiKN23iA6NWjB5iko46hcg%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 [email protected] <javascript:>. >> >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA028yZNyR-_V7j8-GAwHfjKx3VUw5yj%2BiJQV1G9DhdrEw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA028yZNyR-_V7j8-GAwHfjKx3VUw5yj%2BiJQV1G9DhdrEw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> >> *Marcus Ottosson* >> [email protected] <javascript:> >> >> -- >> 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] <javascript:>. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAoJTJpFqRyFvtCC%2BnAbC67an_DPobYEdJ4YVN%2BZVPEyQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAoJTJpFqRyFvtCC%2BnAbC67an_DPobYEdJ4YVN%2BZVPEyQ%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 [email protected] <javascript:>. >> >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3Sxz1WsF4FeCr8Jd3i7bvL3EV4gVX3L-RX%2BzS_NQWAsQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3Sxz1WsF4FeCr8Jd3i7bvL3EV4gVX3L-RX%2BzS_NQWAsQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> >> *Marcus Ottosson* >> [email protected] <javascript:> >> >> -- >> 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] <javascript:>. >> 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 >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBBLEijwy73oeGVL%2B%2By7n_1JpBPKqo_rs%2BmCF10VL3JEg%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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2_1pGbUjbLiEDGrRfSpN_KiLAS1jovgeFyCa7z8C26Xg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2_1pGbUjbLiEDGrRfSpN_KiLAS1jovgeFyCa7z8C26Xg%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/fbadd6f0-94a0-4a9e-acdc-5ee30c710352%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
