Hi Jakob,

> Sigh, I feel thoroughly misunderstood. Am I expressing myself so unclear? If that's the case I apologize. Let's have another try:

Thanks for your effort to broaden our mutual understanding.  The fact
that these menu items are at the nexus of broad and complex topics of
configuration, community and UX, it's no surprise that there's a lot
to say.

In the interests of clarity, I'm going to be liberal in snipping out a
lot of what I consider to be "weeds" in this discussion, so that
what's left will hopefully be a distillation of what's relevant.

> Consequently, my current free time development platform of choice is Squeak. It is not Pharo.

Okay, I didn't know.

>> Are you saying Metacello does not have its own browser and never will?
> (...snip...) Metacello has no browser and I think it never will.

Okay, but for reasons I'll explain below, this does not excuse it back
to the Do menu.

> What I instead wanted to say is that the install item in the Do menu does not make the image less friendly for a newcomer. But it makes it easier for some of us---myself included---to initialize a trunk image to a state from which we can start working.

This is where I would like to ask you to take a step back and imagine
there is _another university_, or perhaps two or three, or five, each
with their own way to "initialize a trunk image to a state from which
we can start working."  We ALL face this issue of "initial
configuration", Jakob.  So far, no one else has added theirs to the Do
menu, not because they agree with Marcel that it isn't much to type
into a workspace, but because they respect that such a thing is
completely unscalable and unsustainable.  The Do menu is like a
"commons".

None of the other parts of the discussion below (SqueakMap, etc.)
really matters beyond the point above, except as it can be interesting
to entertain alternative ideas with you.  I don't want to force you or
anyone to use SqueakMap, just please don't make an unscalable third
place for general-installation of software by polluting the Do menu.
Or, do it only in the university image, not the release image.

>> > It is not a matter of my taste of writing install scripts. It is a matter of how people in general write install scripts (see below). We can procilaim the "correct" way to do that all day long, but it is meaningless if the rest of the world does not agree or does not comply.
>>
>> This entire statement above is completely meaningless...   The "world"
>> does not "agree" on anything, nor is there any need to "agree" or
>> "comply" with anything w.r.t. what we're talking about.
>
> Let me try again by mapping the generalizations in my sentence to more concrete entities:
> - we = actually you and anybody else who says that SqueakMap should be the sole way of loading packages into a Squeak image  (...snip...)
> - the "correct" way to do that = putting the install script for the project on SqueakMap
> - the rest of the world = non-Squeakers, but Smalltalkers, who put their projects on GitHub. Especially Pharoers. Not me, not you.
> - does not agree = they don't want to deal with SqueakMap or don't want to check which loading prerequisites a fresh Squeak Trunk image fulfills and which not (that is Metacello)
> - does not comply = does not include the ensureLatestMetacello line in their readme (maybe they don't even know that it is required in Squeak)

That is exacly how I understood you the first time, and my first
response remains the same.  The problem with your argument is you are
pretending "the rest of the world" group, the "does not agree" group,
and "does not comply" groups actually care about having those items on
the Do menu or on SqueakMap.  Since they don't use or care about
Squeak, they don't.  So correct, we DON'T expect them to make
SqueakMap entries.

The only ones that care about access in Squeak is the "we" (more
specifically, you, Marcel, people loading projects from github into
Squeak).  People who, I guess, want to use Squeak and want it be easy
for them.  That makes YOU the "third person" to make that entry, *even
for projects maintained by others*, because for no other reason that
you want to be able to consume it quickly.  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.

>> ... snip ...

>> >> > Yeah, projects that use Pharo or GemStone as their primary platform will be delighted to hear that they have to maintain a SqueakMap entry to give squeakers a chance to try their stuff. Not!
>> >>
>> >> Of course it's not mandatory, but I think you're kidding yourself if
>> >> you think Users (and even Developers) in 2019 will be delighted to
>> >> know they have to do a lot of research and work (hint:  a lot more
>> >> than 9 clicks) just to figure out how to try out your project.
>> >
>> > Well, the Smalltalk projects on GitHub that I came across typically have an "Installing" section at the top of their README, which is displayed on the project's front page on GitHub. This section often contains a snippet like the following:
>> >
>> >     Metacello new
>> >         baseline: 'NameOfTheProject';
>> >         repository: 'github://...';
>> >         load.

Ah!  This made me just be able to grok Fabio's idea!  Cool!  How about that?

>> > That's easy enough to copy&paste and run and requires less than 9 interactions, *if* Metacello is available in the image already.
>>
>> "Easy enough" means you've accepted a compromise.  You will never
>> achieve a high level of participation until its easier for newbie
>> developers.  But that's not my business, only Squeak's IDE...
>
> Assuming a newbie project maintainer's point of view (not someone who looks at Squeak for the first time), I don't see a more practical solution than a copy&paste-able install script in my readme right now. Forcing newbies to learn how to put entries on SqueakMap does not make Squeak more appealing as a platform, IMHO.

There you go again, talking about "forcing".  I want to state this
very cleearly -- **all of my ideas in this discussion were always
based on not depending on anything from package maintainers**.
Nothing.

Seriously, please align the incentives with the resultant actions in
your analysis and process development.  The basis of your arguments is
always that these two incentives are mis-aligned, which isn't reality.

> Although it is a worthwhile thing to learn. An analogy (as perceived by me): You would not want to force a newbie C GNU/Linux developer to set up a Debian package for the calculator they have just written and are eager to share (...)
>
> 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.?   Maybe the readme should be just one single
line that simply calls an appropriate method on Installer (or
whatever) to do everything.  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...

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.  This does not represent a
commitment to Squeak, and is not an excuse to pollute one of its
commons areas just to make arriving at a half-assed configuration
easier.

I also like Fabio's idea...

> Because "every project" also includes projects whose developers do not use Squeak. But the project might still be interesting for Squeakers.

If it was truly "interesting" to a Squeaker they would want an easy
way to consume, so would not mind cut-and-pasting the load-script into
a SqueakMap entry.  They wouldn't add it to the Do menu.

> For example, there is Clément's Scorch: https://github.com/clementbera/Scorch Clément seems to use Pharo only, but Eliot wants to have Scorch in Squeak. (Though, the most severe hurdle at the moment is that Scorch is kept in Tonel format and tools for that are not yet ready or comfortable to use in Squeak. Eliot's problem is not the fact that the readme does not include the ensureLatestMetacello line.)
>
> 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?   If so, wow, I really do not care for
Metacello, and would not care to have it in my image.

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.

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

I know this doesn't change the fact they could still refuse, but at
least don't let it be for a false reason like that!

> 3) create "third-party-maintained" SqueakMap entries: see below

>> > But as a matter of fact, not all projects include these hints. Because they are built in Pharo and Pharo has the latest Metacello loaded already.  And if they don't use Squeak in the first place, you cannot tell them to go to the SqueakMap.
>>
>> But Jakob, **they don't mention to find the Metacello pre-req on
>> Squeak's Do menu either**, right?  So, either way, newbies trying to
>> use your projects in Squeak are confused and lost.
> ...snip...
>
> You are right, however, that having the menu item in either of the menus won't make it easier to load such projects as a newcomer.
> In my opinion, neither does the snippet buried in "Extending the system" help in that case.

I disagree, because that falls under "Help".  The requirement is we
make a "natural path of discovery", the Help menu is the start of that
path.  The Do menu isn't anywhere on it.

>> Which is sad, because normally someone using Squeak knows about
>> SqueakMap, it's part of their main knowledge / training, because
>> SqueakMap is how projects are loaded in Squeak.
>
> I may be mistaken about that because of my own history, but I doubt that SqueakMap is a well-known tool for people that are relatively new to Squeak. I have never used SqueakMap until roughly a year ago. I have first used Squeak in 2012.
>
> SqueakMap is also not something I remember being used in any university course that I attended and that was related to Squeak. If you would like to challenge and discuss why that was not done, I suggest to do that in a separate thread.

What matters is the future.  What we want Squeak to BE.  Who used it
or didn't in the past is irrelevant, only that, going forward, it
serves those who want the flexibility load _anything_, and know that
it will work.

One thing I'm sure we agree on -- the "Do" menu and readme's are not
the university's "final solution" to this matter.

>> ... snip...
>
>> Barring that, all I ask that we don't confuse how software
>> Installation is done in Squeak.
>
> As written above: You present that as an uncontested fact. I doubt that it is. My doubts might be unjustified, but as a matter of fact software *is* loaded into Squeak images *without* using SqueakMap. Just like someone using Debian GNU/Linux is not restricted to install software exclusively from the official package repositories of that distribution. Although my impression is that the usage rate of apt and the official repository to install software in Debian, Ubuntu etc. is less debatable than the usage rate of SqueakMap in Squeak.

A catalog is catalog.  We both understand what purpose they serve, and
their limitations...

> 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.  The "head" versions which are for devs to load "the latest" are
available for cases like this, but SM's primary purpose is
preservation of working configurations.

> 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.  Either way, no one is
"forced" to do anything whatsoever, but everyone benefits from those
who did voluntarily.

 - Chris