MC Configurations feature request

Hello,

Someone is working on Monticello configuration maps, I think it is David
Lewis. David, would it be possible to add the feature that a config map
can load another config map? I want to set ProCrypto-1-1-1 map to be
loaded by PromisesLoader, loading remote promises.

K, r

On Fri, Jun 5, 2020 at 23:25, Chris Cunningham <[hidden email]> wrote:

Hmm.

So what would be the behaviour if the embedded config had the same package specified as the outer config, but with a different version?

Easiest would be to just do them in order:

Load Package A.2

Load Embedded Config (which load Package A.1, and Package B.4)

Load Package B.3

At the end, you'd end up with A.1 and B.3.

Does the current (i.e., enhanced) version of Monticello configurations keep track of the latest one loaded into the image?  And which repository it came from?  If so, this shouldn't be excessively hard.

However, please never ever do this in the main trunk configuration map!

-cbc

On Fri, Jun 5, 2020 at 8:07 AM Robert Withers via Squeak-dev <[hidden email]> wrote:

Hello,

Someone is working on Monticello configuration maps, I think it is David
Lewis. David, would it be possible to add the feature that a config map
can load another config map? I want to set ProCrypto-1-1-1 map to be
loaded by PromisesLoader, loading remote promises.

K, r

> On 05.06.2020, at 17:06, Robert Withers via Squeak-dev <[hidden email]> wrote:
>
> Hello,
>
> Someone is working on Monticello configuration maps, I think it is David
> Lewis. David, would it be possible to add the feature that a config map
> can load another config map? I want to set ProCrypto-1-1-1 map to be
> loaded by PromisesLoader, loading remote promises.

You can use Metacello to specify dependencies between different projects.
Its completely different from mcms tho. In the end, mcm are just an ordered list of packages…

-t

Yes, I prefer Monticello mcm files. With support for config files
referencing other config files I will be able to form any list, nested.
I really do not have much affinity for Metacello classes and the various
#baselineOf... and #configurationOf... methods and package classes. It
is much complexity and I get confused. I prefer a straightforward list
as a single artifact.

K, r

PS. I would really like a Gradle analog in Smalltalk. Then with
conditional loading rules, we could specify any target build.

On 6/6/20 4:43 AM, Tobias Pape wrote:

On Fri, Jun 05, 2020 at 03:06:44PM +0000, Robert Withers via Squeak-dev wrote:
> Hello,
>
> Someone is working on Monticello configuration maps, I think it is David
> Lewis. David, would it be possible to add the feature that a config map
> can load another config map? I want to set ProCrypto-1-1-1 map to be
> loaded by PromisesLoader, loading remote promises.
>
> K, r
>

Hi Robert,

An MCConfiguration (aka MCM file) is a simple specification of a set of
Monticello package versions. It serves as a checkpoint specification in
an update stream, such as the Squeak trunk update stream. It is not intended
to support dependency management.

Metacello is designed to support more complex configuration specifications.
If a configuration cannot be clearly specified with an MCM configuration map,
then it is probably time to use Metacello to address the issue.

Dave

On 6/6/20 9:49 PM, David T. Lewis wrote:
Hi David,

> An MCConfiguration (aka MCM file) is a simple specification of a set of
> Monticello package versions. It serves as a checkpoint specification in
> an update stream, such as the Squeak trunk update stream. It is not intended
> to support dependency management.

Yet it does so. Quite well, I would observe. My preferred dependency
mechanism needs a tiny little bit more support, configs in configs. I
will pray for this to happen.


> Metacello is designed to support more complex configuration specifications.
> If a configuration cannot be clearly specified with an MCM configuration map,
> then it is probably time to use Metacello to address the issue.

Yuck. I would prefer a first-class build & dependency language, similar
to Gradle[1]. It would provide all the conditional aspects and version
specification for past releases. Also it could be made to callout to
gcc, cmake, autoconf, etcetera. And automatic [git pull; git commit; git
push]. This is the build environment for doing round-trip builds and
investigations, spoken about recently in the vm-dev list.

I am not sure I can express myself effectively, as I don't just want to
say yuck and carry on. I owe an explanation of my opinion. I strongly
dislike the auto-construction of #baselineOf and #configurationOf
methods and their required presence. We should have repositories of
artifacts and dependency specification in a build declaration script.
Call it a .sqm for Smalltalk Qualification Module. This has the protocol
of the new Smalltalk-based Gradle.

Kindly,
Rabbit

[1] Gradle - https://gradle.org/

>
> Dave

On 6/7/20 2:17 PM, Robert Withers wrote:
> I am not sure I can express myself effectively, as I don't just want to
> say yuck and carry on. I owe an explanation of my opinion. I strongly
> dislike the auto-construction of #baselineOf and #configurationOf
> methods and their required presence.

> We should have repositories of
> artifacts, like maven repos, and dependency specification in a build declaration script.
> Call it a .sqm for Smalltalk Qualification Module. This has the protocol
> of the new Smalltalk-based Gradle.

Each projects .sqm file is in the git root directory for that project,
exactly as the POM is for Maven. Andso, it si under git control. As the
POM is specified as the fundamental unit of work, so the SQM file for
Straddle.

Straddle is the Smalltalk analog to Gradle, which helps teams build,
automate and deliver better software, faster. From the inside of an
image. Browse Straddle config file (SQM).

Just wanted to clarify a little bit.

K, rabbit

>
> Kindly,
> Rabbit
>
> [1] Gradle - https://gradle.org/
>
>> Dave

Hi Robert,

Have you tried Metacello recently? The BaselineOf subclass for a
project is very much like the POM in a Maven project or a Gradle file
(whose presence is also required for these kinds of projects). The
Metacello baseline declares which packages belong to this project, and
the dependencies and where they are coming from. It is not
"auto-constructed" as you put it, you write this specification
yourself. And it is declarative, just like Maven or Gradle files
(well, the latter can be turned into imperative style as well AFAIK).
I don't know what is not "first-class" about it as a
bill-of-materials. Put the BaselineOf subclass of the project in a git
repository and you are all set -- in a Git repository you don't even
need the ConfigurationOf part (because a commit usually is exactly one
configuration of your project). The baseline can also declare
conditional loading, to load different parts for different Smalltalk
vendors (Squeak, Pharo, ...).

Metacello has most of the features you asked for, except controlling
external tools (gcc, etc.). But you should rather use external tools
for that (like CMake, Gradle, ...). You can call them from Squeak via
OSProcess if you like. Metacello is not really a build system because
since when have we needed "builds" in a running Smalltalk environment?
It is rather a package manager, like apt. SmalltalkCI [1] is somewhat
of a build system, and it uses Metacello to load packages and their
dependencies into fresh images, in the usual setups.

Why reinvent the wheel?

What's missing in comparison to the Maven/Gradle world is one or more
central repositories to discover Metacello configurations/baselines,
so you could omit the Internet locations of dependencies in your own
projects. But you wouldn't automatically get that with extended
Monticello configurations either. For the older Metacello there is
something like this on SqueakSource already, but since it is
Monticello-based, it is not so appealing for Git-oriented projects,
and consequently Pharo.

I suggest you try Metacello, it is not so bad [2][3]. Its own code is
hard to follow, but not the descriptions you write for your own
projects.

[1] https://github.com/hpi-swa/smalltalkCI
[2] http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Metacello.pdf
(applies to Squeak equally well)
[3] https://github.com/Metacello/metacello/blob/master/docs/GettingStartedWithGitHub.md#create-baseline

Kind regards,
Jakob

Am So., 7. Juni 2020 um 20:24 Uhr schrieb Robert Withers via
Squeak-dev <[hidden email]>:

On Sun, Jun 7, 2020 at 17:52, Jakob Reschke <[hidden email]> wrote:

Hi Robert,

Have you tried Metacello recently? The BaselineOf subclass for a
project is very much like the POM in a Maven project or a Gradle file
(whose presence is also required for these kinds of projects). The
Metacello baseline declares which packages belong to this project, and
the dependencies and where they are coming from. It is not
"auto-constructed" as you put it, you write this specification
yourself. And it is declarative, just like Maven or Gradle files
(well, the latter can be turned into imperative style as well AFAIK).
I don't know what is not "first-class" about it as a
bill-of-materials. Put the BaselineOf subclass of the project in a git
repository and you are all set -- in a Git repository you don't even
need the ConfigurationOf part (because a commit usually is exactly one
configuration of your project). The baseline can also declare
conditional loading, to load different parts for different Smalltalk
vendors (Squeak, Pharo, ...).

Metacello has most of the features you asked for, except controlling
external tools (gcc, etc.). But you should rather use external tools
for that (like CMake, Gradle, ...). You can call them from Squeak via
OSProcess if you like. Metacello is not really a build system because
since when have we needed "builds" in a running Smalltalk environment?
It is rather a package manager, like apt. SmalltalkCI [1] is somewhat
of a build system, and it uses Metacello to load packages and their
dependencies into fresh images, in the usual setups.

Why reinvent the wheel?

What's missing in comparison to the Maven/Gradle world is one or more
central repositories to discover Metacello configurations/baselines,
so you could omit the Internet locations of dependencies in your own
projects. But you wouldn't automatically get that with extended
Monticello configurations either. For the older Metacello there is
something like this on SqueakSource already, but since it is
Monticello-based, it is not so appealing for Git-oriented projects,
and consequently Pharo.

I suggest you try Metacello, it is not so bad [2][3]. Its own code is
hard to follow, but not the descriptions you write for your own
projects.

[1] https://github.com/hpi-swa/smalltalkCI
[2] http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Metacello.pdf
(applies to Squeak equally well)
[3] https://github.com/Metacello/metacello/blob/master/docs/GettingStartedWithGitHub.md#create-baseline

Kind regards,
Jakob

Am So., 7. Juni 2020 um 20:24 Uhr schrieb Robert Withers via
Squeak-dev <[hidden email]>:

>
>
> On 6/7/20 2:17 PM, Robert Withers wrote:
> > I am not sure I can express myself effectively, as I don't just want to
> > say yuck and carry on. I owe an explanation of my opinion. I strongly
> > dislike the auto-construction of #baselineOf and #configurationOf
> > methods and their required presence.
>
> > We should have repositories of
> > artifacts, like maven repos, and dependency specification in a build declaration script.
> > Call it a .sqm for Smalltalk Qualification Module. This has the protocol
> > of the new Smalltalk-based Gradle.
>
> Each projects .sqm file is in the git root directory for that project,
> exactly as the POM is for Maven. Andso, it si under git control. As the
> POM is specified as the fundamental unit of work, so the SQM file for
> Straddle.
>
> Straddle is the Smalltalk analog to Gradle, which helps teams build,
> automate and deliver better software, faster. From the inside of an
> image. Browse Straddle config file (SQM).
>
> Just wanted to clarify a little bit.
>
> K, rabbit
>
> >
> > Kindly,
> > Rabbit
> >
> > [1] Gradle - https://gradle.org/
> >
> >> Dave
>
>