[squeak-dev] The Inbox: System-cmm.1059.mcz

Jakob Reschke forums.jakob at resfarm.de
Mon Apr 8 22:29:44 UTC 2019

Hi Chris,

I think the main conflict point is resolved when the MetacelloStub proposal
is accepted. I still would like to clarify some things for the benefit of
mutual understanding, but I will try to skip the ones that would extend the
debate needlessly.

Am Mo., 8. Apr. 2019 um 03:35 Uhr schrieb Chris Muller <asqueaker at gmail.com

> Remember, #ensureMetacello
> doesn't get you "initialize a trunk image to a state from which we can
> start working," does it?  Because you still have to load whatever
> package(s) you want to actually work on.

In 90% of the cases when I fetch a new image, I will install Metacello
first, then load something with it. That something varies, Metacello does
not. Metacello is the common thing on these paths to the "complete" image,
whatever comes after loading Metacello depends on the case. Metacello is a
bit like a surrogate for SqueakMap in this alternate workflow, but not
completely. And Metacello is not pre-loaded in the image. Imagine the
nuisance if you had to install SqueakMap in every new image first and then
a shortcut to do it that someone else recently added were removed. ;-) So
much about my feelings for that menu entry. Fabio's suggestion and your
implementation with the MetacelloStub solves the problem without the need
for a menu entry, so it's the best of both worlds. Thank you.

> Second, even if you put up a SqueakMap entry, you have two things to
> maintain now: your readme (which you have to keep for Pharo, for example)
> and the SqueakMap entry. More on that maintenance further down this message.
> So you're writing and maintaining multiple lines of code in a README
> that is not subject to the benefits of SCM version control and
> in-browser editing, etc.?

No, the readmes are under version control, in Git.

I don't know whether people ever edit them using Squeak, or Pharo, but I
guess they don't. Files can be edited directly on GitHub and that usually
is the quickest way for the readme because you can immediately see the
results of the Markdown formatting. So it even is in-browser editing,
albeit not with a Smalltalk browser. ;-) (This time, it really is a joke...)

Maybe the readme should be just one single
> line that simply calls an appropriate method on Installer (or
> whatever) to do everything.

The readmes on GitHub are also "regular" readme files, which contain the
project description etc. Like the descriptions on SqueakMap.

Maybe even such readme script could be
> accessed directly off the network from within Squeak?  Then,
> theoretcally, you wouldn't have to "maintain" it...   But, this method
> of doing configuration is quickly shows its limitations...

I thought a moment about automatically collecting SqueakMap entries out of
GitHub projects. That is, finding them with the search if you conduct one.
But there are all kinds of issues, such as reliably detecting the proper
install script (there might be more than one) that applies to Squeak. And
it could only provide head configurations, no stable ones, unless you put
yet much more effort in. And it would, of course, find projects that won't
work at all in Squeak and cannot even be loaded even if Metacello were
already in the image.

Furthermore, what you're trying to do is expect software written for
> Pharo to install and work on Squeak with zero code or effort for
> platform-specific configuration issues.

No I never expect that such an attempt will be painless. Not even for
proper Squeak projects in a trunk image. But actually I can seldom expect
that from software in general. Still, hope dies last.

> > The case is that these projects might not "wish to [officially] support
> Squeak", but Squeakers might wish to use them anyway. And in my opinion,
> even if Squeak is at a disadvantage in this case, Squeak should not put
> more obstacles, or rather nuisances, in the way than necessary. That's why
> my favorite solution would be to have Metacello in each trunk image (we
> discussed about such inclusion and its problems with Marcel in the other
> thread).
> Having Metacello in the image does not eliminate any obstacle to
> accessing those projects.  **You still need to know the load script**
> to load them.  Are you saying these scripts are in Metacello without
> loading the actual project?

No no, the scripts and Metacello configurations are only in the
repositories of these projects. The code snippet to trigger Metacello to
actually load the project is placed in the readme to have it easily found.
So when you find something on GitHub and wish to load it, the load script
is usually right in front of you, you don't have to know it.

The scenario I have in mind has a different starting point than the one you
seem to have in mind: you seem to think of "I want to load project Xyz and
I have Squeak in front of me. I go to the SqueakMap to load it", which
makes sense (in particular if you are willing to create an entry if it does
not exist yet). I think of "I am in my web browser and have project Xyz in
front of me and would like to load it in Squeak. It has a (Metacello) load
script in its installation instructions, so I go to Squeak (need Metacello)
and run that load script". So in my case, the project and the load script
is already found. Searching it again in SqueakMap feels a little redundant.
However, you are right: if there is a working and up-to-date configuration
(or one creates it), and one ever wants to load Xyz again, this will be an
attractive way to go for next time.

> The workaround solutions are:
> > 1) make Metacello as quickly installable as possible: the Do (or
> whatever) menu item
> You keep conflating this with access to the projects (as provided in 2
> and 3, next).  This is the "halfway configured" state.  This is not a
> "solution" to configuration.

That's right, it does not get me to the final configuration. But it does
make these GitHub projects (and their dependencies) accessible at all. That
was the purpose all along. It was better than nothing or getting to the
halfway-configured state in more cumbersome ways. The new MetacelloStub
lets us skip that state.

> > 2) post pull requests to those projects and add that
> ensureLatestMetacello line: might be rejected because the maintainers don't
> want to assume responsibility for the project to work in Squeak
> MIT license states "softare is AS IS", how in the world does
> "ensureMetacello" line suddely make maintainers "responsible"?

License aside, if someone had a "do this to load in Squeak" section in
their text, I would assume that they support Squeak somehow. Also note that
Pharo does not have the ensureRecentMetacello method AFAIK, so one cannot
include that line in a general install script in the readme without
mentioning Squeak. Again, with the MetacelloStub, there is no need to even
ask for the line anymore.

> To avoid a further misunderstanding: I don't think that SqueakMap should
> not be used or were the wrong tool for the purpose. I rather think that you
> might overestimate its current role.
> Not at all.  I know exactly what its responsibilities and limitations
> are.

About that I had no doubts. I meant its popularity, but somehow that word
didn't come to my mind yesterday, sorry. However, I did a little research
and must acknowledge that my impression stems from the very limited
exposure to SqueakMap at university. Most projects I know from there I
don't find on SqueakMap. And since nobody uses Squeak in my regular
surroundings today, that covers most of the projects I know. So my
perception on that is indeed biased, as I feared.

> I don't remember seeing anyone using SqueakMap in front of my eyes, and I
> have seen many screens with Squeak. Yet, my perception might be biased,
> that's why I would be interested in that poll.
> As I said before, such a thing is totally irrelevant to voluntaryists;
> past, present, or future.  If a github project sufficently interests
> someone in Squeak, they'll make a SqueakMap entry for it to serve them
> personally.  If it doesn't, they won't.

It's not that simple. I know some squeakers personally who care very much
about Squeak and they put a lot of effort into it. But their attention
apparently does not extend to SqueakMap, and neither did mine. They
probably have valid reasons, but I better refrain from trying to advocate
any further. I have spent far too many hours of possible sleep on this
discussion already. ;-) Have a nice day everyone.

Kind regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190409/6350c5ca/attachment-0001.html>

More information about the Squeak-dev mailing list