Sean,
What do I think? I think that's a loaded question:)
Honestly? I THINK that we've reached a cross roads for Monticello/Metacello. I
THINK of Metacello as a pontoon bridge that keeps goods and services flowing
while we build the real bridge.
The "relentless evolution" of Pharo puts pressure on all parts of the
ecosystem, in a good way.
As developers, this evolutionary pressure is experienced as pain:
- pain in having to port perfectly good code to
yet another version of Pharo
- pain in having to wait for other developers to
port their projects
- pain in finding new bugs in parts of the system
that "used to work"
- pain in having to work in a system without the
high level tools that you'd like (because they
haven't been ported yet)
This is not a complaint. This is the reality. We can fold under the pressure or
we can grow stronger.
Pharo is evolving for all of the right reasons so we must respond and evolve
and relieve the pain without surrendering progress:
Change is painful.
Change is necessary.
Therefore pain is necessary.
Metacello was originally developed to address specific pain points. It did a
good job of addressing pain in some areas and not so good in other areas and of
course, it also introduced a set of new pain points...
Monticello/Metacello spans the following broad areas:
version control
configuration management
build management
And the strain of trying to address each of these areas is showing.
I THINK that it doesn't make sense to continue to try to address all three
areas under one umbrella. The version control area is probably Metacello's
weakest point and is the area where the most difficult technical problems
remain to be addressed.
I THINK the best answer at the point is to divide and conquer.
Thus the "crossroads."
I THINK that Git/GitHub is superior to Monticello/Metacello/SqueakSource. See
my talk on "Practical Git for Smalltalk" for my arguments[1].
I THINK that as a community we will be better off embracing the technology
available in Git/GitHub than reinventing that wheel. Not only does Git/GitHub
make it possible to share Smalltalk source between dialects (by having shared
source code format[2] and a shared version control system), but Git/GitHub
removes one of the barriers that newcomers to Smalltalk face: Git/Github is
familiar to millions of developers.
By eliminating version control responsibility from Metacello and embracing
Git/GitHub a whole set of pain points are addressed.
We have the new pain points of learning and using Git/GitHub, but with
Metacello we have yet to INVENT the capabilities that Git/GitHub brings to the
table, so I THINK we are ahead of the game by embracing Git/GitHub.
If you skim through the "Metacello Scripting API" README[3] you'll get a taste
of how I THINK Metacello can bridge the gap between
Monticello/Metacello/SqueakSource and FileTree[4]/Metacello/Git/GitHub. Don't
get me wrong, there are still some areas to be figured out ... Symbolic
versions occupy a unique niche in our environment and I haven't quite figured
out a way to replace them in the git/github world....
I THINK that the two worlds (mcz and git) must coexist for a long time so there
must be a seamless integration of the two.
The scripting API is being designed such that it can be included in the base
image, so I THINK the scripting API (and Git/GitHub) will go a long ways
towards removing the mystery from Configuration loads, while making the
supporting tool set easier to build.
I am still working out some of the finer points of integrating Metacello and
Git/Github, but I'm hoping to have some concrete developments in the next month
or so ...
Dale
[1] http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk
[2] https://github.com/CampSmalltalk/Cypress/blob/master/README.md
[3]
https://github.com/dalehenrich/MetacelloScriptingApiSpec/blob/master/README.md
[4] https://github.com/dalehenrich/filetree/blob/master/README.md
----- Original Message -----
| From: "Sean P. DeNigris" <[email protected]>
| To: [email protected]
| Sent: Friday, April 27, 2012 9:08:17 PM
| Subject: Re: [Pharo-project] What about making the configuration browser
more visible?
|
|
| Schwab,Wilhelm K wrote
| >
| > Put another way, if it's that simple, why all the contrary
| > instructions
| > over time?
| >
|
| I understand your frustration. We are like parents watching a child
| grow
| up...
|
| For one thing, the API has been evolving as we've learned. From
| loadLast/Latest, to bleedingEdge/development, now to symbolic
| versions
| (which were sorely needed).
|
| The other impediment was that Metacello couldn't be assumed to have
| preloaded any base classes. Thus, ConfigurationOfXxx classes rely on
| someone
| manually (or automatically via tools) adding convenience methods.
| Without
| these, the API is hidden away in the project class.
|
| Recently, there seemed to be some agreement between Squeak and Pharo
| to load
| some base Metacello classes. If Configs had a common subclass, I
| think the
| system browser would be much more helpful.
|
| Dale, what do you think about all this?
|
| HTH,
| Sean
|
| p.s. of course ultimately, success depends on people testing projects
| and
| updating the configs...
|
| --
| View this message in context:
|
http://forum.world.st/What-about-making-the-configuration-browser-more-visible-tp4590573p4594228.html
| Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
|
|
