<div dir="auto"><div dir="ltr"><div dir="ltr"><div>Hi Chris,</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Fr., 5. Apr. 2019 um 02:44 Uhr schrieb Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank" rel="noreferrer">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"><br>
I also recognize a perception on your part of Squeak and its community<br>
being like the group identified on the home-page of <a href="http://github.com" rel="noreferrer noreferrer" target="_blank">github.com</a>:<br>
<br>
"Built for developers"<br>
<br>
so hope you won't mind me reminding that the audience for Squeak goes<br>
beyond that group. Squeak should continue to cater to Users, because<br>
they're not as tough as Developers. As a developer, you can<br>
appreciate a modular system capable of loading IDE plug-ins.<br></blockquote><div><br></div><div>I know that Squeak does not target developers only. But it *also* targets developers.</div><div dir="auto"><br></div><div>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.</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>
> 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></blockquote><div><br></div><div>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.</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. </blockquote><div><br></div><div>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:</div><div><br></div><div> Metacello new</div><div> baseline: 'NameOfTheProject';</div><div> repository: 'github://...';</div><div> load.</div><div><br></div><div>That's easy enough to copy&paste and run and requires less than 9 interactions, *if* Metacello is available in the image already.</div><div><br></div><div>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.</div><div><br></div><div>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. 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.</div><div dir="auto"><br></div><div dir="auto">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.</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></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">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. 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).</div><div dir="auto"><br></div><div dir="auto">Best regards,</div><div dir="auto">Jakob</div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div></div></div>