FWIW, I am working on a project called Rowan that is a replacement for 
Metacello ... Right now I am working on integrating Rowan into the 
GemStone build process and the plan is that Rowan will be included in 
the next major release of GemStone ... Like Metacello, Rowan is aimed at 
multiple dialects of Smalltalk.

All of the project/package metadata is stored external to the packages 
directory. Here is a very simple example project[1] that has 2 
packages[2] RowanSample9-Core and RowanSample9-Tests. The 
RowanSample-Tests package is conditionally loaded. if you poke around in 
the rowan directory[1], you will see that the project meta data is being 
stored on disk in STON format.

Rowan supports both Filetree and Tonel package formats.

There are nearly 60 different sample projects in the RowanSample9 
repository[3] each on it's own branch and all of the projects were 
created and updated using the Rowan API. The Rowan API encompasses not 
only creating and managing project meta data, but the creation and 
management of projects/packages/classes/methods.

The "Rowan API" is segregated into two major pieces: disk format and 
in-image api.

The most important piece of the API is the disk format as that is the 
key to sharing projects between smalltalk dialects. At a minimum all 
dialects must be able to share the disk format.

The second component is the in-image api. The in-image api is in roughly 
three pieces: Rowan definitions (similar to Monticello definitions ... 
extended to include projects and the in-image representation of the meta 
data; a loader api which manages the work of installing definitions into 
the image; and the loaded representation of projects, packages, classes 
and methods.

I'm imagining that different dialects will choose to support Rowan at 
different levels. Sharing disk format only; sharing the definition 
implementation (which would include reading and writing definitions 
to/from disk); sharing the loader implementation; and sharing the loaded 
implementation.

Esteban, Mariano and I talked in December/January about incorporating  
sub applications, etc. into Rowan, but we were all under time 
constraints at the time and it seems that incorporating the Envy meta 
data was going to take a little bit of work. Rowan has the notion of 
`components` which are very similar to subapplications, but 
subapplications are more restrictive than components[4] and there was no 
opportunity for directly mapping between the two --- without spending a 
bit of time that we didn't have ... with that said I am optimistic that 
Envy metadata can be incorporated.

The fact that Rowan serializes objects to disk in STON format, means 
that we can have quite a bit of latitude in what how we shape the 
metadata that is stored on disk --- which means that if push comes to 
shove, Envy style projects may use a different set of classes than the 
"standard Rowan project (akin to Metacello/Monticello projects)". Of 
course, the Envy style projects should be loadable and writable on all 
supported platforms ...

I am still a couple months away from being done with V2.0 of Rowan 
(Rowan V1.0 went into production at one of our customer's sites 1.5 
years ago) and I will have other tasks related to the next release of 
GemStone, so I can't forecast when I will start porting Rowan to other 
platforms, but that is my intention.

In the mean time, if there are folks interested in helping with the port 
to other platforms, please drop me a line and we can arrange a chat :)

Dale

[1] https://github.com/dalehenrich/RowanSample9/tree/spec_0001/rowan
[2] https://github.com/dalehenrich/RowanSample9/tree/spec_0001/rowan/src
[3] https://github.com/dalehenrich/RowanSample9
[4] https://github.com/GemTalk/Rowan/issues/553
On 5/29/20 12:50 PM, Mariano Martinez Peck wrote:
>
>
> On Fri, May 29, 2020 at 4:34 PM Jakob Reschke <forums.jakob at resfarm.de 
> <mailto:forums.jakob at resfarm.de>> wrote:
>
>     Hi Mariano,
>
>     That is interesting to hear, thank you!
>
>     What is VA Smalltalk's stance about Tonel interoperability between the
>     Smalltalks _in the same project_? For example, if the main developers
>     use VA Smalltalk, there will be the additional ENVY properties for
>     SubApplications and such in the meta files. But when someone loads the
>     project in Squeak or Pharo and writes another version, this will not
>     include these additional properties. So if this person created a pull
>     request, merging it without manual polishing will "destroy" the
>     additional setup for VA Smalltalk.
>
>     I am asking because we are facing similar problems between Squeak and
>     Pharo, although they are still much closer to one another than VA
>     Smalltalk is to any of them.
>
>
>
> Yes, that would be the current situation. Although, if you can live 
> with certain constrains (like not having subapps, loosing whether a 
> method is public or private, etc etc), then its much closer to be 
> interoperable. You can read more here: 
> https://github.com/instantiations/tonel-vast#compatibility-recommendations
>
> Also, we have an open  issue to address the possibility of storing the 
> VA specific metadata in a separate place: 
> https://github.com/instantiations/tonel-vast/issues/49
> But we have a bunch of other higher priority things first.
>
> Hope this helps.
>
> -- 
> Mariano Martinez Peck
> Email: marianopeck at gmail.com <mailto:marianopeck at gmail.com>
> Twitter: @MartinezPeck
> LinkedIn: www.linkedin.com/in/mariano-martinez-peck 
> <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/>
> Blog: https://marianopeck.wordpress.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200529/c2c4daf9/attachment.html>