<div dir="ltr"><div dir="ltr">Hi Chris,<div><br></div><div>Sigh, I feel thoroughly misunderstood. Am I expressing myself so unclear? If that's the case I apologize. Let's have another try:</div><div><br></div><div>Some general remarks at the beginning: when I write about "those GitHub projects", I do not (only) mean my own projects. I mean Smalltalk projects on GitHub in general. Many of them are developed in Pharo, I suppose, since Pharo had the better Git support first (with GitFileTree and later Iceberg).</div><div><br></div><div>My own hobby projects are </div><div>1) Squot/Squit/FileSystem-Git, which has the installGitInfrastructure snippet you removed from the Do menu in its readme: <a href="https://github.com/hpi-swa/Squot/blob/develop/README.md" target="_blank">https://github.com/hpi-swa/Squot/blob/develop/README.md</a> The text below that does not include ensureLatestMetacello because it was written before either of those methods existed in the Installer class.</div><div>2) the "bare minimum" Tonel fork for Squeak, which has the ensureLatestMetacello line in its readme: <a href="https://github.com/j4yk/tonel/blob/squeak/README.md" target="_blank">https://github.com/j4yk/tonel/blob/squeak/README.md</a></div></div><div>And actually, I have no other ongoing hobby software development projects at the moment, except if you also count the Squeak version of FileSystem which I dug into for FileSystem-Git (which is, like FileSystem, something I picked up, rather than invent).</div><div><br></div><div>Consequently, my current free time development platform of choice is Squeak. It is not Pharo.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Sa., 6. Apr. 2019 um 04:38 Uhr schrieb Chris Muller <<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> I do not see the conflict in this case. Having a shortcut to install Metacello is nothing like twisting the concept of Morphic, turning your browser into a command line tool, or showing debugging annotations on every graphical widget, or something like that. It is not invasive. Neither are the refactoring tools. They extend the system browser, which is a developer's tool anyway.<br>
<br>
Are you saying Metacello does not have its own browser and never will?<br></blockquote><div><br></div><div>Well, that's not what I said, but actually it is true: Metacello has no browser and I think it never will. Metacello configurations, or rather only baselines in the case of Git projects, are written with the system browser; they are Smalltalk code. See <a href="http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Metacello.pdf" target="_blank">http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Metacello.pdf</a> (also applies to Squeak)</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>> > These projects place a Metacello load script in their README files.<br>
>><br>
>> I wasn't trying to change you if you have a special use-case or<br>
>> preference for doing configuration that way.<br>
><br>
> 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.<br>
<br>
This entire statement above is completely meaningless...   The "world"<br>
does not "agree" on anything, nor is there any need to "agree" or<br>
"comply" with anything w.r.t. what we're talking about.<br></blockquote><div><br></div><div>Let me try again by mapping the generalizations in my sentence to more concrete entities:</div><div>- we = actually you and anybody else who says that SqueakMap should be the sole way of loading packages into a Squeak image. I put myself in these shoes in partial agreement with you and, to be less dismissive, wrote "we" instead of "you". Unfortunately there are no separate pronouns known to me that distinguish "others and me, including you" (which is what I meant) from "others and me, but without you" (which you might have interpreted).</div><div>- the "correct" way to do that = putting the install script for the project on SqueakMap</div><div>- the rest of the world = non-Squeakers, but Smalltalkers, who put their projects on GitHub. Especially Pharoers. Not me, not you.</div><div>- 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)</div><div>- does not comply = does not include the ensureLatestMetacello line in their readme (maybe they don't even know that it is required in Squeak)</div><div><br></div><div>So to put it together again: I do make sure that the readme of my projects has a snippet that can be run in a fresh trunk image and it will load everything that is needed. I could, and probably should, put that exact snippet on SqueakMap, too. The current state of affairs is that there are other projects on GitHub (not mine) that don't include the ensureLatestMetacello line. Because they are probably not aware that it is required in Squeak. Nobody can blame them for that if they only work in Pharo and have never used Squeak. Even if we would agree that the best way is to register the project on SqueakMap, and that every project with a Metacello configuration should include the ensureLatestMetacello line in their installation instructions (readme) for Squeak, it would not change the fact that the maintainers of those projects will probably do neither of that.</div><div><br></div><div>The case where a third person creates a SqueakMap entry for such a project I will comment below.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>> > 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!<br>
>><br>
>> Of course it's not mandatory, but I think you're kidding yourself if<br>
>> you think Users (and even Developers) in 2019 will be delighted to<br>
>> know they have to do a lot of research and work (hint:  a lot more<br>
>> than 9 clicks) just to figure out how to try out your project.<br>
><br>
> 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:<br>
><br>
>     Metacello new<br>
>         baseline: 'NameOfTheProject';<br>
>         repository: 'github://...';<br>
>         load.<br>
><br>
> That's easy enough to copy&paste and run and requires less than 9 interactions, *if* Metacello is available in the image already.<br>
<br>
"Easy enough" means you've accepted a compromise.  You will never<br>
achieve a high level of participation until its easier for newbie<br>
developers.  But that's not my business, only Squeak's IDE...</blockquote><div><br></div><div>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. 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 (...)</div><div><br></div><div>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.</div><div><br></div><div>Third, "easy enough" actually means "very easy" for someone who does not have Squeak open in front of them for the first time. The precondition to meet is to be able to use a workspace and evaluate code in it. That does not apply to a Squeak user who never touches any Smalltalk code. If that's your point, I agree with you.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Some projects (typically those developed in Squeak) include the hint for Squeak that you first have to install the latest Metacello because it is not included in Squeak. Ideally every project would also include the Installer ensureRecentMetacello snippet.<br>
<br>
Why don't they?   If they wish to support Squeak, then that's a<br>
configuration error in those packages, full stop.<br></blockquote><div><br></div><div>Because "every project" also includes projects whose developers do not use Squeak. But the project might still be interesting for Squeakers. For example, there is Clément's Scorch: <a href="https://github.com/clementbera/Scorch" target="_blank">https://github.com/clementbera/Scorch</a> 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.)</div><div><br></div><div>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). The workaround solutions are:</div><div>1) make Metacello as quickly installable as possible: the Do (or whatever) menu item</div><div>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</div><div>3) create "third-party-maintained" SqueakMap entries: see below</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 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.<br>
<br>
But Jakob, **they don't mention to find the Metacello pre-req on<br>
Squeak's Do menu either**, right?  So, either way, newbies trying to<br>
use your projects in Squeak are confused and lost.<br></blockquote><div><br></div><div>This particular point is not about newbies (I'll switch back to newcomers since it sounds nicer to me). But if you have read all the latest posts, you have found out that it is contested whether the Do menu is a thing for newcomers, or rather a thing for "power users". I count myself among the people that assumed the latter.</div><div><br></div><div>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. For that, it should rather read "How to install software in Squeak". But the actor in the use case I describe is not a newcomer. It is a developer or a Squeak power user.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Which is sad, because normally someone using Squeak knows about<br>
SqueakMap, it's part of their main knowledge / training, because<br>
SqueakMap is how projects are loaded in Squeak.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On the other hand, we should not dismiss them or their projects just because they don't know or care enough about supporting Squeak. That would be a huge, arrogant mistake, IMHO.<br>
<br>
I'm not sure why you feel dismissed when it's actually Squeak that's<br>
being dismissed -- by omitting ensureMetacello at the top of your<br>
project README's, and further by trying to compensate for this by<br>
trampling Squeak's menu with your personal hack that confuses and<br>
dilutes the hard work that went into making configuration in Squeak a<br>
breeze for anyone; developer or user.<br></blockquote><div><br></div><div>See above: Your interpretation of me feeling dismissed or having omitted the Metacello line is false as I did not refer to me or my projects.</div><div>I referred to the kind of projects I described above instead.</div><div><br></div><div>Otherwise I would not have used the pronouns "they", "them", and "their", but rather "we", "us", and "our".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> If a Squeaker tries to maintain the SqueakMap entry for such a project, it is doomed to become stale sooner or later in my opinion.<br>
<br>
As someone in Pharo-land, I don't expect you to understand SqueakMap<br>
or the goals it solves, but just so you know, correctly defined<br>
SqueakMap configurations _never_ get stale.<br></blockquote><div><br></div><div>How did you get the impression that I am "someone in Pharo-land"? I only start Pharo when I have to look up how something works there when I port something to Squeak. It would not make much sense to develop Git tools for Squeak if I would use Pharo primarily, wouldn't it? Not being used to Pharo, I very much favor Squeak. I am not even subscribed the Pharo mailing list at this time.</div><div><br></div><div>But I have different workflows in Squeak and different opinions about that than you have, Chris. And, since it seems to me that you have never used Metacello or maintained a Squeak project outside of Monticello or changeset-land, I also use different tools. Though, I am not an exceptional case on that matter, believe me.</div><div><br></div><div>On the meaning of "stale": I know that a non-head SqueakMap configuration will continue to work for a particular Squeak release because the configuration is expected to pin down the version of the project being loaded. What I meant is that there might be no updated, new configurations for new versions of Squeak or the project. SqueakMap entries for Squeak 3.x don't help me if I am not also willing to use that old Squeak version. SqueakMap entries that are several years old for a project that has evolved since then don't help me either if I want to use the newer version. I consider this a "stale" project entry as well, although its dated configurations may still work fine.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>> That's<br>
>> what SqueakMap was designed to solve:  fixed configurations that<br>
>> present the project, and work forever on a particular version.  It's<br>
>> targeted to helping _others besides you_ configure their system so<br>
>> they can evaluate your project's latest working version to decide if<br>
>> they want to invest the time in setting up a dev configuration.  But<br>
>> often others will capture load scripts and document them on SqueakMap<br>
>> for themselves, you don't have to do it if you don't want.<br>
><br>
><br>
> That's all nice and I see the benefit. You don't have to convince me. But the reality is that it places a burden on the project or entry maintainers.<br>
> The devs have to step outside their repository to make their stuff more easily available. A third person that creates a SqueakMap entry assumes the responsibility to retest that project for every new release and update the entry. It might be simple, but it is not at all appealing for someone who only uses Squeak as a hobby (or not at all).<br>
<br>
You made the argument above that "it is doomed to become stale" but<br>
then above you say, "responsibility to test".  Which is it Jakob?<br></blockquote><div><br></div><div>It is not a contradiction at all. If someone creates an entry, but does not assume that responsibility, the entry will become stale. And even if someone is aware of that responsibility and assumes it wittingly, they might change their mind or lose interest at a later time. Or they simply don't have time for Squeak anymore. The consequence: the entry (the project on SqueakMap) becomes stale (as in my definition). Unless somebody else picks it up, but the cycle may repeat.</div><div><br></div><div>Of course, it does not *always* happen that people leave Squeak and their SqueakMap entries behind. So "doomed" as in "destined" is indeed an exaggeration, sorry.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As I tried to explain above, neither.  Because if a project is worth<br>
installing for someone else, THEY will do it.  If it isn't, they<br>
won't.</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In the meantime, I hope you'll close the gap in your configurations<br>
with a "ensureMetacello" at the top of your README's.  You can easily<br>
be inclusive of all platforms OOTB without hurting Pharo at all, if<br>
you want to be.<br></blockquote><div><br></div><div>See above, you misunderstood me.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Barring that, all I ask that we don't confuse how software<br>
Installation is done in Squeak.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>We could have a poll to capture the current usage of SqueakMap both from a user's and a maintainer's point of view, but again I propose to move that to a separate thread. Also I acknowledge that the poll would be biased by the fact that not every Squeak user is on the mailing list.</div><div><br></div><div>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. 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.</div><div><br></div><div>Kind regards,</div><div>Jakob</div></div></div>