What Top-Level Metacello Operation Am I Inside?

Sean,

Sorry for the delay in getting to this question ...

First off, did you already figure things out?

If not, it's not clear to me what the difference is other than in the End-User Use Case, the end-user would load ResourcesLive directly:

Metacello new
	baseline: 'ResourcesLive'
	repository: 'github://XXX/ResourcesLive:master/repository'
	load: 'Default'.

and the Library use would be accomplished by encoding the Metacello doit in a BaselineOMyCoolProject project reference:

...
spec
	baseline: 'ResourcesLive'
	with: [
		spec
			loads: 'Default';
			repository: 'github://XXX/ResourcesLive:master/repository' ].
...

In the Library use case you may publish a different group that would be used for library references, but that would only be necessary if the Library use case required a different set of packages ... If so you might publish a 'Library' group that collected those libraries together ...

Dale

For SimplePersistence, I'm trying to have a concept of libraries being in "Library" mode (i.e. loaded as a dependency of a larger project) or "End-User" mode (i.e. used as-is). In "Library" Mode, persistence should not be automatically be enabled because the other project will want to save the library's objects to keep the object graph intact. Given the two cases below:

End-User Use Case

- Metacello load ResourcesLive

Library Use Case

- Metacello load My-Cool-Project

    - Metacello load ResourcesLive (as dependency)

How would I distinguish between them?

Thanks!

Sean

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/dc9821ce-0434-4edc-bcc1-c4705517bfd8%40googlegroups.com.

I'm sorry when I'm being so dense, but I misunderstood the first time, so I want to make sure I know what you're talking about this time ...

AFAICT, we've got ResourcesLive and MyCoolProject dependency on ResourcesLive .... so where does the "MetaC post-load doit" fit in ... Is this something associated with the ResourcesLive project or the MyCoolProject or is MetaC yet  another entity? Is "MetaC post-load doit" going to be in a BaselineOf and if so where is it sitting?

If I were to guess, this seems like a case where a Library group (and associated separately loaded package with Library post-load doit) and a separate top-level group (and associated separately loaded package with a Top-level post-load doit) would be called for?

What does you MetaC post-load doit need to do differently?

Dale

Sorry for the delay in getting to this question ...

No problem :)

 

First off, did you already figure things out?

Nope :/

 

If not, it's not clear to me what the difference is other than...

Sorry, I think I was not sufficiently clear. I meant how would I distinguish from code. For example, let's say I had a MetaC post-load doit and I wanted to do different things depending on whether I was in a top-level or dependent MetaC load?

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/178aead1-e7ca-4fcb-b340-056119099e98%40googlegroups.com.

What does you MetaC post-load doit need to do differently?

I guess I was looking for something that would happen automatically behind the scenes without the user (whether via library or end-user) having to worry about it, so they could use one script and get the right result.

But that "one script" will have an indication of whether or not it is using "a library" or "the app", so it is a matter of the end user choosing between the two (or more) ways of "using the thing they want to use" ... so I am not sure where the "automatic" comes into play ... if a post load doit for the "library" package and a different post load doit for the "application" package fills the bill then there is your answer ... or am I missing something else?

I _am_ interested in a specific answer to the "What does you MetaC post-load doit need to do differently?", because I am creating Rowan as we speak ...

Rowan has a "component" which is the loadable entity ... In Metacello "everything" was a loadable entity: package, group, and project ...

A "component" is a declared _and_ maintained chunk of functionality, so in Rowan there could be an 'Application' component and a 'Library' component and the end user would choose to load one or the other depending upon what behavior/API they are looking for ... components will have post load doits (in the next week or so?:) ...

So I am interested in what other attributes and behind the scenes automation you are expecting (in more concrete terms) so I can try to include support for these in Rowan components.

So being a little more specific would help me understand what it is you think you are missing in Metacello ...

Dale

Dale Henrichs-3 wrote
But that "one script" will have an indication of whether or not it is 
using "a library" or "the app"

Maybe I'm oversimplifying, but I envisioned these two use cases:

"End-User Mode" which would load via MetaC scripting API

   Metacello new

baseline: 'ResourcesLive';

repository: 'github://seandenigris/ResourcesLive';

load.

"Library Mode" which would load via another baseline

   spec baseline: 'ResourcesLive' with: [

spec repository: 'github://seandenigris/ResourcesLive' ]

I wanted to avoid having to specify additional information like a group.

Maybe I'm being too picky? I guess it wouldn't be much more code to have:

   spec baseline: 'ResourcesLive' with: [

spec repository: 'github://seandenigris/ResourcesLive';

loads: 'Library-Mode' ]

I don't know about picky, but there needs to be something that differentiates between "Library Mode" and "End-User Mode" so that the correct initialization procedure is run ... some one has to tell Metacello what doit to run and when ... and for Metacello that's a post load doit associated with a package ...

Dale Henrichs-3 wrote
I _am_ interested in a specific answer to the "What does you MetaC 
post-load doit need to do differently?"

In "End-User" mode, ResourcesLive would be responsible for it's own

persistence, so it would enable that (currently in a class-side initialize)

[1]. In case it's relevant, the real work in that method happens in

SimplePersistence here [2]

Thanks for the info ... I think I've got a clearer picture about what you are trying to do and I might have this covered for Rowan ... in Rowan there is the notion of a component. The component is the THE loadable entity in Rowan (as opposed to package, group, project in Metacello) and a component is a list of (conditional) package names and/or component names ... and a component has (will have:) pre and post load doits, so in your case there would be an "End-User" component and a "Library" component and each would have a unique post load doit ... There's only so much you can squeeze into a Metacello baseline spec method and only so much meta data (basically none:) that you can add to a package ... so it would take a substantial rewrite of Metacello to add the notion of "component" to Metacello...

Thanks for the information,

Dale

1.

https://github.com/seandenigris/Resources-Live/blob/586dd82c9cc1da3a6e6e3354b4cf8bd833862795/src/ResourcesLive/ResourcesLiveDB.class.st#L24

2.

https://github.com/seandenigris/Simple-Persistence/blob/master/src/SimplePersistence-Core.package/SpFileDatabase.class/class/setUp.st

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/metacello/14384984-99b6-49c0-9925-3f751e71da2a%40googlegroups.com.