<div dir="ltr"><div dir="ltr">Hi Chris,<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 8. Apr. 2019 um 03:35 Uhr schrieb Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@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">Remember, #ensureMetacello<br>
doesn't get you "initialize a trunk image to a state from which we can<br>
start working," does it?  Because you still have to load whatever<br>
package(s) you want to actually work on.<br></blockquote><div><br></div><div>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.</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">
> 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.<br>
<br>
So you're writing and maintaining multiple lines of code in a README<br>
that is not subject to the benefits of SCM version control and<br>
in-browser editing, etc.? </blockquote><div><br></div><div>No, the readmes are under version control, in Git.</div><div><br></div><div>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...)</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">Maybe the readme should be just one single<br>
line that simply calls an appropriate method on Installer (or<br>
whatever) to do everything.</blockquote><div><br></div><div>The readmes on GitHub are also "regular" readme files, which contain the project description etc. Like the descriptions on SqueakMap.</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">Maybe even such readme script could be<br>
accessed directly off the network from within Squeak?  Then,<br>
theoretcally, you wouldn't have to "maintain" it...   But, this method<br>
of doing configuration is quickly shows its limitations...<br></blockquote><div><br></div><div>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.</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">Furthermore, what you're trying to do is expect software written for<br>
Pharo to install and work on Squeak with zero code or effort for<br>
platform-specific configuration issues.</blockquote><div><br></div><div>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.</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">> 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).<br>
<br>
Having Metacello in the image does not eliminate any obstacle to<br>
accessing those projects.  **You still need to know the load script**<br>
to load them.  Are you saying these scripts are in Metacello without<br>
loading the actual project?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</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">> The workaround solutions are:<br>
> 1) make Metacello as quickly installable as possible: the Do (or whatever) menu item<br>
<br>
You keep conflating this with access to the projects (as provided in 2<br>
and 3, next).  This is the "halfway configured" state.  This is not a<br>
"solution" to configuration.<br></blockquote><div><br></div><div>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.</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">> 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<br>
<br>
MIT license states "softare is AS IS", how in the world does<br>
"ensureMetacello" line suddely make maintainers "responsible"?<br></blockquote><div><br></div><div>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.</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">> 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.<br>
<br>
Not at all.  I know exactly what its responsibilities and limitations<br>
are.<br></blockquote><div><br></div><div>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.</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">> 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.<br>
<br>
As I said before, such a thing is totally irrelevant to voluntaryists;<br>
past, present, or future.  If a github project sufficently interests<br>
someone in Squeak, they'll make a SqueakMap entry for it to serve them<br>
personally.  If it doesn't, they won't.</blockquote><div><br></div><div>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.</div><div><br></div><div>Kind regards,</div><div>Jakob</div></div></div>