Hi Dale,

2016-11-10 6:04 GMT+01:00 Dale Henrichs <dale.henrichs@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.henrichs@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.

��

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