On Thu, Nov 10, 2016 at 10:12 AM, Thierry Goubier <thierry.goub...@gmail.com > wrote:
> Hi Dale, > > 2016-11-10 6:04 GMT+01:00 Dale Henrichs <dale.henri...@gemtalksystems.com> > : > >> >> >> On 11/8/16 7:09 AM, Thierry Goubier wrote: >> >> Hi Dale, >> >> 2016-11-08 2:03 GMT+01:00 Dale Henrichs <dale.henri...@gemtalksystems.com >> >: >> >>> [ snip ... ] >>> >>> yes I think this is the area where a Metallo Project Browser comes into >>> play. The technology for committing the dirty packages in a a >>> ConfigurationOf has been around for quite awhile, but a tool that unifies >>> the "multi-package" commit for ConfigurationOf and BaselineOf hasn't popped >>> out of the wood work ... >>> >> >> I'm having some issues with the scripting approach of Metacello, for >> that. Just manipulating a baseline in the Metacello registry (locking it) >> seems to be like writing a compiler code generation item: write a Metacello >> script ;) (Metacello>>#lock contains interesting code). >> >> I think I agree:) ... that is why i am talking about a tool ... >> developers shouldn't have to pass around workspaces to load and manipulate >> projects .. a project tool can partially automate the process, but I >> believe that there needs to be a "load spec" object that can be passed >> around and massaged by code instead of requiring a user to edit a Smalltalk >> workspace ... it's what I do in tODE ... the only times I have to write >> Smalltalk load scripts is when I work in Pharo :) >> > > Agreed. I would just like to find out which object can be used to act upon > (can I call lock on a Metacello project spec... apparently not :))... I'm > not too keen on adding another layer on top of it, first because I'm not > that found of unneeded layers, second because it may mean a significant > rewrite of the environment (have dozens of methods like MyLayer>>#load > which is just a call to Metacello load) to get something that starts > working. > > I'm not in a position to impose large scale changes in the Pharo > ecosystem; it's the consortium role to take and impose such choices. I can > only, like GitFileTree, inject something at a lower level that allow people > to complement and experiment with... > >> >> >> I will repeat that I don't think Pharo should do exactly what I've done >> with tODE, but a Metacello Project Browser and some sort of "load spec" >> object that is shared amongst a cluster of images is something that needs >> to be seriously considered ... >> > > I'm really willing to also make something helping to work with Baselines / > Configurations because I think they present a significant complexity > barrier to the proper use of Metacello features, and I don't see any path > avoiding us to write those, given how complex it may be. > Now a BaselineOf is a ConfigurationOf but such things cannot be put in the Catalog because well, there is some incompatibility happening. Getting BaselineOf usable right away would be a small step but a great step. I find myself having to write a BaselineOf for the Git repo and a ConfigurationOfXXX usign the old scheme to be put in the Catalog and pointing to the BaselineOf. Could someone point to the reason why? > >> >> >>> >>> >>> What is a bit annoying, really, is this talk of rewriting everything >>> where some of the pieces (the project browsing you're talkin about, for >>> example) is already there in the image, just not exposed. >>> >>> Well I am annoyed as well .. I would say that perhaps we are in >>> screaming agreement ... I've said that I don't think it's a lot of work to >>> do the project-centric tool. but a project-centric tool that encompasses >>> both ConfigurationOf and BaselineOf will expose the features that "are >>> already there" >>> >>> >>> I'm trying to code a little something for that... stay tuned for a >>> screenshot soon. >>> >>> Cool:) >>> >> >> And here it is! I'm still fighting with the Metacello lock / unlock thing. >> >> [image: Images intégrées 1] >> >> If Pharo was more really modular in configurations and baselines, then I >> would see more things into the registry and I could group packages based on >> that (instead of having to prepare a ad-hoc classification for my my >> browser). >> >> Yes this is headed in the right direction ... I am in Argentina this week >> so it isn't easy for me to do much collaboration, but I would love to help >> you with your lock problem next week ... For example ... you do not want to >> directly expose the Metacello registry as there are "hybrid projects" where >> a ConfigurationOf causes a BaselineOf to be loaded, so the BaselineOf needs >> to take precedence (I have code for resolving this) and I strongly suggest >> that the Project Browser not be built-into the Class Browser, but be a >> separate tool like the CataLogBrowser ... but this is just a suggestion --- >> a separate tool dedicated only to loaded Projects and unloaded Projects of >> interest allows one to get a very quick overview of what is in the project >> or not and when version skew pops up, one can easily see the affected >> projects ... embedding this kind of information in the code browser can >> make it hard to get the overview and if you choose to live with version >> skew can be annoying to ignore .... again these are just my thoughts .. >> > > I'm of a different mind on this. Giving access to the Metacello registry > explains well to me what is happening in the system; as long as the GUI > accelerate a significant subset of the common operations, then I'll > consider it good enough and have it working on a short time frame. > Already having the GTPlayground showing an inspector after loading is nice these days. Before it was more convoluted to understand what was going on. The inspector panes kind of rewrite things their way but still nice to have. > Otherwise, you end up with projects like libgit / Iceberg, which are > taking significantly longer to reach a better solution... Exposing the > exponential time needed to reach the perfect solution. > What is Iceberg trying to solve exactly? Ah, and I found why my Pharo5 image explodes when using GitFileTree on Windows: because of ProcessWrapper trying to use git which is in turn not in the path, and then boom. > > I also hate information duplication: why do I have to write a complex > project spec where most (all?) of it has to be rewritten in a different > form in a BaselineOf? Same goes for the forks you described the other day: > why do I have to write in my project description the information I also > have to add inside the repository (an upstream remote) to manage updating > with the master project? > There is too much stuff to understand to get anything used by a layman. There isn't so much to do with tools like npm.js etc: write your json thing for the package, use semver and this is all looking logical. So that one can get a junior dev handle it in a day. Try that with what we have. Phil > > For version skew, I must be a bit like git designers on that. It has to be > an action (a git pull), and this action is required in git anyway (git pull > upstream / git pull origin) .. I have no opinion on whether a GUI has to > automatically check that everytime I open the project browser. > > >> >> Regardless I think you are definitely headed in the right direction and >> it isn't all that much work ... yet:) >> > > I need to keep it reasonable to be able to tackle it :) > > Thierry > > >> >> >> Dale >> > >
