> On 09.09.2019, at 18:46, tim Rowledge <tim at rowledge.org> wrote:
> 
> 
> 
>> On 2019-09-09, at 12:53 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>> 
>> I'd say that, if we use Metacello, lets use the new form consistently:
>> 
>> 	Metacello  new
>> 		"squeaksource: 'MetacelloRepository'; "  "<-- this is the default for mcz-based Configurations"
>> 		configuration: 'RefactoringTools';
>> 		"verison: #stable; "  "<-- this is the default"
>> 		load.
> 
> If those are defaults then why not allow
> Metacello new
> 	load:: 'RefactoringTools'
> ?

The shortest variant do date is:

	Metacello new
		configuration: 'RefactoringTools';
		load.


> And I do hope the search for the configuration name is case insensitive.

That's not how it is supposed to work.

See, Metacello startet as classes that describe
	"configurations of software (ie, a bunch of MCZs) with dependencies" together with code to bootstrap everywhere because noone had metacello preinstalled.

When Dale started to support filetree-serialization and Git/GitHub, he found that the state of a directory (or working copy of git/whatever) served as the precise combination of (Monticello-ish) versions of packages. That's where the baselines come from.

He simplified things into the 'Metacello new ...' api.

When before he had the MetacelloRepository at SqueakSource to host all the single-class ConfiguraionOf... MCZs as a canonical way, for Git stuff, there was no such way (or not yet) to canonically look up ConfigurationOf/BaselineOf's for projects.

So when before it was

	Installer ss
		project: 'MetacelloRepository';
		addPackage: 'ConfigurationOfRefactoringTools';
		install.
	(Smalltalk at: #ConfigurationOfRefactoringTools) project load: '2.0'.

It really said
- Locate the MCZ for RefactoringTools, which canonically is called "ConfigurationOfRefactoringTools", which canonically lives in http://www.squeaksource.com/MetacelloRepository
- install it so we get the class, canonically named "ConfigurationOfRefactoringTools"
- make it into a MetacelloProject instance (maybe with bootstrapping) 
- load version '2.0' through the project.


The "complete" version for the new api would be:

Metacello new
	repository: 'http://www.squeaksource.com/MetacelloRepository';
	configuration: 'ConfigurationOfRefactoringTools';
	className: 'ConfigurationOfRefactoringTools';
	version: '2.0';
	load.


=-=-=

Note that Metacello now keeps a registry of installed projects, so if we would rely on the pre-'Metacello new..' behavior of checking whether all monticello-packages are at the desired version, Dale got us covered: just replace 'Metacello new' by 'Metacello classic'.

=-=-=

I suggest browsing around Metacello and MetacelloToolBox :)

------------------------------------

To answer the actual "why not `Metacello new load: 'RefactoringTools'`?", there are some reserved "actions" for metacello.
The easiest is "load", which, well, retrieves and installs the necessary software; but it got a companion "load:", where you can specify what _parts_ of the software you want. Remember Seaside:

	Metacello new
		configuration: 'Seaside3';
		smalltalkhubUser: 'Seaside' project: 'MetacelloConfigurations'; 
		"^--- lives somewhere else, not canonical"
		onConflictUseLoaded;
		"^--- explicit conflict resolution, yay"
		version: #'release3.2';
		load: #('OneClick' 'Security' 'Filesystem' 'Email' 'RSS' 'REST').
		"^--- specify the components you want"


Besides "load", there is 
	- "get" to retrieve or refresh the class describing you project (ie, the ConfigurationOf or BaselineOf) but nothing else;
	- "fetch" to just download all necessary mcz-filed or git-checkouts or the like;
	- "record" to simulate a "load" but not acutally do it
and some other stuff to lock versions of projects in place.

The class comment on Metacello is quite extensive in that regard :)

Best regards
	-Tobias



> 
> tim