Installer metacello

Wait, what, who pressed that button?

Anyway - a side issue relating to this discussion. Project names and class names; hint - they don't need to be the same!

A user level class for accessing OojamwigglePlus project facilities doe NOT need to be named something utterly unguessable nor longwindedly projectname+moreverbiage.

Metacello may well be a great project etc etc but it's not the most obvious thing to lok for when you're wanting to use an installer to install some code. That might be sometihng named, ooh, maybe "installer" ?

> On 2020-04-30, at 9:55 AM, tim Rowledge <[hidden email]> wrote:
>
>
>
>> On 2020-04-30, at 1:57 AM, Marcel Taeumel <[hidden email]> wrote:
>>
>> Installer has a very big advantage: its name. That name is descriptive und discoverable. We should benefit from that and evolve Installer into something we all like. :-)

This is, amongst other things, why we have HostWindow* instead of AriethffaFenestriWindowProxy etc.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A sad tale that brings a lump to the eye and a tear to the throat.

If it was named Installer on GS/Pharo/Cuis too, then yes.
Otherwise, firm No.

Best regards
        -Tobias

On Thu, Apr 30, 2020 at 12:37:30PM +0200, Marcel Taeumel wrote:
> Let's make it more concrete. I prefer sprinkle "Installer ..." calls in the system compared to "Metacello new". Here are some examples:
>
> - Adding a menu entry to the world menu such as "Git browser (click to install)"
> - Adding a list entry to the preferences wizard's "install extra packages" page such as "installOSProcess"
>

<OT>

Regardless of the outcome of this discussion, please note that Metacello
should not be used to install OSProcess/CommandShell. Nothing against
Metacello, it is just not appropriate for this case.

Thanks,
Dave

</OT>

+1

I see nothing to be gained from a common API for distinct dependency
management models (i. e., there is not really any integration)
https://xkcd.com/927/