On Tue, Sep 8, 2015 at 7:25 PM Marcus Ottosson <[email protected]> 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]> > wrote: > >> >> >> On Tue, Sep 8, 2015 at 6:15 PM Marcus Ottosson <[email protected]> >> 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]> >>> wrote: >>> >>>> >>>> >>>> On Tue, Sep 8, 2015 at 8:11 AM Marcus Ottosson <[email protected]> >>>> 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]. >>>>> 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]. >>>> >>> 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] >>> >>> -- >>> 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/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]. >> > 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] > > -- > 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/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]. 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.
