Re: split of mockup / plone.mockup
Alex Clark <[email protected]>
| Newsgroups | gmane.comp.web.zope.plone.devel |
|---|---|
| Message-ID | <[email protected]> |
On 3/10/15 8:21 AM, Ramon Navarro Bosch wrote: > I understand that mockup whats to be a bower component but I don't see > why it can't be a bower component and at the same time a python egg, if > its mockup-core that breaks because of that maybe we can change > mockup-core, a js piece of code that is also on our codebase. Adding > submodules adds CI problems, complexity and it will more difficult to > track mockup inside plone. > > As I understand mockup is first a project born in plone as its widgets > js framework, and its widgets are inside plone as its any of its > codebase, so first is a plone package, from the plone community that > serves plone needs. I want that mockup is a bower component that can be > reused, but I don't want to priorize this in front of a good setup for > plone. > > One important point is that I would love to have discussed that before > applying on the code, half of my sites are affected by this situation. At a glance, git submodules strikes me as "heavy" too. If we were building Plone from scratch today, what would we do? We'd still probably include static resources in a Python package. Whether or not those components are bower-enabled does not matter too much in the overall context of the entire Plone application bundling (although yes, bower is a very nice tool indeed.) I can easily see a scenario like this: $ mkdir plone/some/core_component $ cd plone/some/core_component $ mkdir static $ cd static $ bower install mockup $ git add * ; git commit -m "Add mockup" ; git push Then later bower update those resources and push a new package to PyPI. > > Ramon > > El dt., 10 març, 2015 a les 10:57, Patrick Gerken > (<lists-Hgn/qBBDvdzwVR/[email protected] > <mailto:lists-Hgn/qBBDvdzwVR/[email protected]>>) va escriure: > > Hi, > > looking back at the original statement, why to split up mockup and > plone.mockup, you mentioned that you did it because you had too many > errors= > in > mockup-core. > I fail to see how using git submodules is the right solution for this > problem. > > Best regards, > > Patrick > > On 10.03 09:30, Johannes Raggam wrote: > > bin/buildout should have checked out the mockup submodule. > > Well, I see it's not optimal. Instead of reverting back to the old > > state, let's find a better solution. IMO, even a workflow of > exporting > > the mockup repository and copying it manually over to > plone.mockup would > > be better than not being able to depend on mockup from own > projects. The > > old situation prevents to create custom bundles without forking > mockup > > and doing the changes directly in there. > > > > Cheers, Johannes > > > > > > On Tue, 2015-03-10 at 07:27 +0100, Timo Stollenwerk wrote: > > > FYI: I just ran into a problem with the plone.mockup pkg: > > > > > > ConfigurationError: ('Invalid value for', 'package', 'ImportError: > > > Module plone has no global mockup') > > > > > > I just did a "git pull", "bin/buildout" and "bin/alltests" on an > > > existing and working buildout.coredev. > > > > > > I had to do a "git submodule update" on the plone.mockup repo > manually > > > to fix this. > > > > > > Let's please remove that package until we find a better > solution. We > > > can't just use buildout.coredev as a playground for new and > untested stuff. > > > > > > BTW: my main point was actually that nested and complex > structures are a > > > bad idea in general, the CI problems are just a symptom of that. > > > > > > Cheers, > > > Timo > > > > > > Am 09.03.2015 um 21:06 schrieb Johannes Raggam: > > > > Hi, > > > > > > > > good arguments! That was a quick shot from me, sorry. But I > think we > > > > agree, that Mockup needs to be a bower installable package. > > > > > > > > So, Timo's point is, that we need for each commit on mockup a > > > > corresponding commit on plone.mockup to get understandable and > > > > reproducable Jenkins result. > > > > > > > > As far as I understood it (didn't try out yet), ``git > subtree``, instead > > > > of ``git submodules`` might be able to solve this problem. See: > > > > > http://blogs.atlassian.com/__2013/05/alternatives-to-git-__submodule-git-subtree/ > <http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/> > > > > > > > > I'm not sure how this works out with mr.developer. Maybe we > need some > > > > Github Webhooks to update the subtree on every Mockup commit. > > > > > > > > Johannes > > > > > > > > > > > > On Mon, 2015-03-09 at 15:41 -0300, Leonardo Rochael Almeida > wrote: > > > >> Hi, > > > >> > > > >> > > > >> I don't know if this is relevant, and you might already be > aware of > > > >> it, but I'd just like to point out that, with git > submodules, the > > > >> submodule is pinned to a specific commit (hash), not a > specific branch > > > >> of the referenced repository. > > > >> > > > >> > > > >> In practice this means that, for the `plone.mockup` > repository to pick > > > >> up a new commit/release/branch/whatever of the `mockup` > submodule, a > > > >> new commit needs to be added to the `plone.mockup` > repository picking > > > >> up this new commit (hash) of the submodule. > > > >> > > > >> > > > >> This also means that any CI that monitors a branch (or > master) of the > > > >> `plone.mockup` repository and blindly calls `submodule > update` on it > > > >> whenever it detects a new commit on the `plone.mockup` will > > > >> automatically pick up changes in the submodules without any > added > > > >> detection complexity. > > > >> > > > >> > > > >> Cheers, > > > >> > > > >> > > > >> Leo > > > >> > > > >> On 9 March 2015 at 15:26, Timo Stollenwerk > <tisto-z4DKO/[email protected] > <mailto:tisto-z4DKO/[email protected]>> wrote: > > > >> Am 09.03.15 um 19:08 schrieb Timo Stollenwerk: > > > >> > Hi Johannes, > > > >> > > > > >> > making mockup installable via bower is a worthwile > goal. > > > >> Thanks for > > > >> > working on that! > > > >> > > > > >> > Though, I see a problem with using git submodules. > It is > > > >> already quite > > > >> > hard to create a proper CI setup on top of > mr.developer, and > > > >> using git > > > >> > submodules will make this even harder. Here is why: > > > >> > > > > >> > We are basically nesting our development packages > into our > > > >> main > > > >> > repository with mr.developer. This makes it hard to > > > >> impossible to > > > >> > trigger one Jenkins job per commit (we tried very > smart > > > >> stuff with > > > >> > mr.roboto and we failed miserably, you have to > store every > > > >> single hash > > > >> > value and every version pinning for each pkg and > re-run > > > >> buildout with > > > >> > this). We are still aiming for 1 commit = 1 build. > Though, > > > >> adding a > > > >> > second nested level (git submodules) within our > already > > > >> nested setup > > > >> > will make this impossible. We might be able to > somehow pin > > > >> our modules > > > >> > if we do releases in the future. We are not going > to be able > > > >> to do this > > > >> > in a structure that is nested twice. > > > >> > > > > >> > Futhermore, my personal experience with git > submodules is > > > >> that even when > > > >> > working with in manually, it is nothing but > unpredictable > > > >> pain. > > > >> > > > > >> > In addition to the uncertainty that buildout and > > > >> mr.developer already > > > >> > put into our CI setup, you just introduced another > one. > > > >> > > > > >> > I think we should try to find another way to solve > this > > > >> problem. I'm not > > > >> > sure if we still take "mockup should be used > outside Plone" > > > >> seriously. > > > >> > Though, in any case I think we should test and release > > > >> mockup > > > >> > separately. What if the mockup CI system (travis?) > creates a > > > >> new release > > > >> > if all unit tests pass. The Plone CI could pick up the > > > >> latest release > > > >> > and we would just have to make sure the travis job > triggers > > > >> the Jenkins > > > >> > CI. Plone would just install the latest mockup > development > > > >> version via > > > >> > bower. > > > >> > > > >> > > > >> Sorry, I mixed things up with the CI pipeline for my > current > > > >> project. :) > > > >> > > > >> We do not want to run npm/bower on our Jenkins job. > Therefore > > > >> we would > > > >> need a Python egg for each mockup commit that can be > picked up > > > >> by the > > > >> Jenkins job instead of a bower release. I guess we > could set > > > >> up a > > > >> private pypi for that if necessary. > > > >> > > > >> Cheers, > > > >> Timo > > > >> > > > >> > ------------------------------__------------------------------__------------------ > > > >> Dive into the World of Parallel Programming The Go > Parallel > > > >> Website, sponsored > > > >> by Intel and developed in partnership with Slashdot > Media, is > > > >> your hub for all > > > >> things parallel software development, from weekly > thought > > > >> leadership blogs to > > > >> news, videos, case studies, tutorials and more. Take > a look > > > >> and join the > > > >> conversation now. > http://goparallel.sourceforge.__net/ > <http://goparallel.sourceforge.net/> > > > >> _________________________________________________ > > > >> Plone-developers mailing list > > > >> Plone-developers@lists.__sourceforge.net > <mailto:Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> > > > >> > https://lists.sourceforge.net/__lists/listinfo/plone-__developers > <https://lists.sourceforge.net/lists/listinfo/plone-developers> > > > >> > > > >> > > > >> > > > >> > ------------------------------__------------------------------__------------------ > > > >> Dive into the World of Parallel Programming The Go Parallel > Website, sponsored > > > >> by Intel and developed in partnership with Slashdot Media, > is your hub for all > > > >> things parallel software development, from weekly thought > leadership blogs to > > > >> news, videos, case studies, tutorials and more. Take a look > and join the > > > >> conversation now. http://goparallel.sourceforge.__net/ > <http://goparallel.sourceforge.net/> > > > >> _________________________________________________ > Plone-developers mailing list > Plone-developers@lists.__sourceforge.net > <mailto:Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> > https://lists.sourceforge.net/__lists/listinfo/plone-__developers > <https://lists.sourceforge.net/lists/listinfo/plone-developers> > > > > > > > > > > > > > > > > > ------------------------------__------------------------------__------------------ > > > > Dive into the World of Parallel Programming The Go Parallel > Website, sponsored > > > > by Intel and developed in partnership with Slashdot Media, is > your hub for all > > > > things parallel software development, from weekly thought > leadership blogs to > > > > news, videos, case studies, tutorials and more. Take a look > and join the > > > > conversation now. http://goparallel.sourceforge.__net/ > <http://goparallel.sourceforge.net/> > > > > > > > > > > > > > > > > _________________________________________________ > > > > Plone-developers mailing list > > > > Plone-developers@lists.__sourceforge.net > <mailto:Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> > > > > > https://lists.sourceforge.net/__lists/listinfo/plone-__developers > <https://lists.sourceforge.net/lists/listinfo/plone-developers> > > > > > > > > > > > ------------------------------__------------------------------__------------------ > > > Dive into the World of Parallel Programming The Go Parallel > Website, sponsored > > > by Intel and developed in partnership with Slashdot Media, is > your hub for all > > > things parallel software development, from weekly thought > leadership blogs to > > > news, videos, case studies, tutorials and more. Take a look and > join the > > > conversation now. http://goparallel.sourceforge.__net/ > <http://goparallel.sourceforge.net/> > > > _________________________________________________ > > > Plone-developers mailing list > > > Plone-developers@lists.__sourceforge.net > <mailto:Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> > > > > https://lists.sourceforge.net/__lists/listinfo/plone-__developers > <https://lists.sourceforge.net/lists/listinfo/plone-developers> > > > > > > > > ------------------------------__------------------------------__------------------ > > Dive into the World of Parallel Programming The Go Parallel > Website, sponsored > > by Intel and developed in partnership with Slashdot Media, is > your hub for all > > things parallel software development, from weekly thought > leadership blogs to > > news, videos, case studies, tutorials and more. Take a look and > join the > > conversation now. http://goparallel.sourceforge.__net/ > <http://goparallel.sourceforge.net/> > > > _________________________________________________ > > Plone-developers mailing list > > Plone-developers@lists.__sourceforge.net > <mailto:Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> > > https://lists.sourceforge.net/__lists/listinfo/plone-__developers > <https://lists.sourceforge.net/lists/listinfo/plone-developers> > > ------------------------------__------------------------------__------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your > hub for all > things parallel software development, from weekly thought leadership > blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.__net/ > <http://goparallel.sourceforge.net/>_________________________________________________ > Plone-developers mailing list > Plone-developers@lists.__sourceforge.net > <mailto:Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> > https://lists.sourceforge.net/__lists/listinfo/plone-__developers > <https://lists.sourceforge.net/lists/listinfo/plone-developers> > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > > > > _______________________________________________ > Plone-developers mailing list > Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/plone-developers > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/