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. > > >> >> >> 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. 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. 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? 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 >
