About Magritte Seaside

Hi guys

How can I get Magritte seaside (and a working version not one breaking
on XML I do not what)?
I loaded the published stable version of Magritte into Pharo and there
is no seaside version.
I checked the configuration and it is so complex....

I have the impression that we need to distinguish Magritte from Magritte
seaside. So
I will do a separate configuration of magritte seaside.

Stef

> On Oct 6, 2015, at 11:11 AM, stepharo <[hidden email]> wrote:
>
> Hi guys
>
> How can I get Magritte seaside (and a working version not one breaking on XML I do not what)?
> I loaded the published stable version of Magritte into Pharo and there is no seaside version.
> I checked the configuration and it is so complex….

I think you have to load the “Seaside" group of ConfigurationOfMagritte3, but I am not sure.. A month ago I played
with Magritte and Seaside and I basically loaded a bunch of configurations until it worked.

As a new user I loaded “MagritteMagic” without knowing better. This one is broken if you load it on Pharo 4.
Later I found out that MagritteMagic was just for demonstration purposes. So maybe it should get an “example” or “demo”
tag in the Project Catalog.

On 06-10-15 11:11, stepharo wrote:
> I will do a separate configuration of magritte seaside.

You need to load the correct groups. Separate configurations are a bad
practice and should be eliminated, not encouraged. The configuration has
a lot of essential complexity, as many different combinations of
components are needed in different situations. We need tools that
recognize that essential complexity and support it, not tools that try
to hide it and then have no practical usability.

Stephan

Le 6/10/15 11:40, Stephan Eggermont a écrit :
> On 06-10-15 11:11, stepharo wrote:
>> I will do a separate configuration of magritte seaside.
>
> You need to load the correct groups. Separate configurations are a bad
> practice and should be eliminated, not encouraged.

I totally disagree.
And groups are not supported by the configurationBrowser
> The configuration has a lot of essential complexity, as many different
> combinations of components are needed in different situations. We need
> tools that recognize that essential complexity and support it, not
> tools that try to hide it and then have no practical usability.

Well I disagree. And all the effort of christophe for the new
dependencies declarations at the package level just goes in that direction.
I will do a MagritteSeaside Configuration that I will maintain and I
will also do a MagritteTutorial one.

>
> Stephan
>
>
>

The many configurations of GT/Glamour have not exactly convinced me.

For a configuration that works when just loading #'stable' from the
configuration browser, I'd suggest trying with the configuration of
BootstrapMagritte. That only runs into the #subStrings: vs #substrings:.

Stephan

On 10/6/15 5:10 AM, stepharo wrote: Stef,

I hope you and Christophe are considering cross platform considerations
when implementing "new dependencies declarations at the package level"
... MonticelloConfigurations had "package level dependencies" and the
implementation was extremely rigid to the point where it wasn't possible
to substitute an alternate (platform-speicific) package in the package
graph without creating new package versions of all packages in the graph
... Of course I am not aware of the approach that Christophe, but be
aware that "there be dragons there":)

Dale

Hi dale.

I will let christophe answers because I do not know the details. I know
that he is working hard on it.
Ideally I would like to have a ConfigurationOf for each package because
it would reduce the bloat of the actual configurationOf and
also be closer to the package. But if I say that people will start
shouting that I'm mad :) (I'm not fool and I'm right :).
so this is why we are doing it inside the package but we will see.
First the core bootstrap based on dependencies ;)

Stef

On 10/6/15 11:43 AM, stepharo wrote:
Stef,

Basing things on a "configuration" external to the package structure
itself will avoid the MetacelloConfiguration limitations.

 From your description, it sounds like Christophe might be
"deconstructing" the project configuration in some way --- I would be
interested in more details ...

Thanks,

Dale

Hi Dale,

Le 6 oct. 2015 à 20:23, Dale Henrichs a écrit :
Thanks for the warning. cross-platform packages are integrated into this new approach by allowing to express dependencies to virtual packages (idea from debian OS: http://www.debian.org/doc/debian-policy/ch-binary.html#s-virtual_pkg). It allows low-coupling and is very flexible.
You will find more information in the paper published at IWST'14: https://hal.inria.fr/hal-01086083/document (by the way, you should already have it, I sent it to you last year but you were very busy at this time ;) )

To summarize in a few words, we want dependencies expressed at the package level (and we want more meta-data on packages), we want to decouple a released version of a package from the working copy of the package version description (implies the creation of a package repository + a web interface on top of it to promote/search packages).
We also want to detect dependencies automatically as much as possible to avoid missing or not-used dependencies (dependency analyser tool). All together, it will allow to define architectural rules and layers in Pharo. I now experimenting all that with the Pharo bootstrap.

If you have any question or remark, do not hesitate to ask or to give feedback.

Christophe.

On 07/10/15 08:47, Christophe Demarey wrote:
> If you have any question or remark, do not hesitate to ask or to give feedback.

How do you express the migration of functionality from one package to
another? How does that affect users of those packages?
How do you intend to deal with variants (as in the 5D model)?

Stephan

Hi Stephan,

Le 7 oct. 2015 à 10:22, Stephan Eggermont a écrit :

> On 07/10/15 08:47, Christophe Demarey wrote:
>> If you have any question or remark, do not hesitate to ask or to give feedback.
>
> How do you express the migration of functionality from one package to another? How does that affect users of those packages?

I don't get what you mean. Could you describe a use case?

> How do you intend to deal with variants (as in the 5D model)

You can group commonalities in package assemblies. For specifities, you could use virtual packages to decrease the number of assemblies to write. In a common assembly, you could describe a dependency to a virtual package. Then you will have concrete packages providing this virtual package, each of them having its own dependencies and working on a specific platform.

Christophe

Christophe,

I still don't have a lot of time to read the paper and try to understand
what you are trying to accomplish, but I am curious how you think
"package dependencies" will play with git-based projects?

In git-based repositories I don't think you have the same type of
dependency issues that one might have with monticello repositories ---
In a monticello repository you have a whole range of possible package
versions to pick from, but in a git-based repository the range of
package versions is fixed to those that are committed together so the
packages that are meant to work together are committed together.

In the bootstrap scenario, you would only have one version per package
to choose from, so the packages that are meant to work together are
committed together ....

I guess I don't know what you mean when you say:
> we want to decouple a released version of a package from the working
> copy of the package version description (implies the creation of a
> package repository + a web interface on top of it to promote/search
> packages).
Perhaps a description of the problem being solved would help me understand.

Dale


On 10/6/15 11:47 PM, Christophe Demarey wrote:

Le 11/10/15 00:40, Dale Henrichs a écrit :
> Christophe,
>
> I still don't have a lot of time to read the paper and try to
> understand what you are trying to accomplish,
you should read it. :)
We wrote it for that and it is not boring nor long.

> but I am curious how you think "package dependencies" will play with
> git-based projects?
>
> In git-based repositories I don't think you have the same type of
> dependency issues that one might have with monticello repositories ---
> In a monticello repository you have a whole range of possible package
> versions to pick from, but in a git-based repository the range of
> package versions is fixed to those that are committed together so the
> packages that are meant to work together are committed together.

I think that this is only true for packages committed within the same repo.
Now between porjects published in different repo you have to express them.
I do not think that we all want to publish in the same repo and clone
out everything. We want to be able to have a package market place where tools can grab
dependencies without to load code
and can compute the set of packages that should be loaded.

When a package is released into the market: then it externalise its
metadata so that a crawler can automatically build
dependency graph and create specific distribution.

Stef

On 10/11/15 12:19 AM, stepharo wrote:
>
>
> Le 11/10/15 00:40, Dale Henrichs a écrit :
>> Christophe,
>>
>> I still don't have a lot of time to read the paper and try to
>> understand what you are trying to accomplish,
> you should read it. :)
> We wrote it for that and it is not boring nor long.
I scanned through it at the time and as I recall, I thought that the
functionality described was already covered by git and BaselineOf ...
but I did not read it in great detail and I did not (and still don't)
have the time to compose a long-winded response:) ... and inter-project dependencies is what a BaselineOf does .... which
brings me back to the conclusion that I reached when I scanned the paper:) Okay. This is a problem .... but it happens to be a problem that
Metacello "can solve/does solve" - so there must be something else (a
deeper problem?) that I don't quite understand.

With that said, if you are planning to replace Metacello, then I am
excited:) But I will repeat that I hope that you are considering cross
platform issues ...

Perhaps at this point in time, I'd like to read some code. Then I can
skip reading the paper and get a feel for how hard it will be to port to
GemStone:)

Dale

Yes probably but you have to have a BaselineOf for every package.
Because we want to have the dependency expressed in every package and
not in
a gigantic "project" configuration of.

>>
>> When a package is released into the market: then it externalise its
>> metadata so that a crawler can automatically build
>> dependency graph and create specific distribution.
> Okay. This is a problem .... but it happens to be a problem that
> Metacello "can solve/does solve" - so there must be something else (a
> deeper problem?) that I don't quite understand.
But you have to load the configuration and somehow execute it so that it
computes the dependencies and we do not want.

> With that said, if you are planning to replace Metacello, then I am
> excited:) But I will repeat that I hope that you are considering cross
> platform issues ...
Yes we do. First we wanted to make it work. Then we should have kind of
virtual packages that act as platforms or project level

> Perhaps at this point in time, I'd like to read some code. Then I can
> skip reading the paper and get a feel for how hard it will be to port
> to GemStone:)
I do not know where christophe save his code but it is be public.

>
> Dale
>
>

On 10/11/15 11:40 AM, stepharo wrote: If you are talking about ConfigurationOf, then I agree that they can be
gigantic, but 99% of the junk in a configuration is completely
eliminated when you use a BaselineOf ... 99% of the junk in a
configuration is dedicated to plugging the gap between monticello as an
SCM and built-in capabilities for git ...

A BaselineOf has a single baseline method and only the "pure"
dependencies amongst the packages and projects needs to be expressed ...
and these dependency specs are about "as small" as you can get ... Do you recall that I have been reminding folks that the specifications
for ConfigurationOf and BaselineOf will someday become an XML file? ...
I have taken great pains over the years to preserve this "expectation"
... Remember the choice to use classes was made as a bootstrap
convenience to avoid having to create tools ... 6 years later and there
is still a dearth of tools:)

When you "execute" the code in a ConfigurationOf or BaselineOf, a
completely separate data structure is constructed using a well-defined
API and it is this "data structure" that does the real work ... it would
be very easy to convert a BaselineOf into an XML/JSON/STON file without
losing any information, unless you've have disregarding my warnings:)

There is nothing in Metacello "project specifications" that _depends_
upon executing code ...
>
>> With that said, if you are planning to replace Metacello, then I am
>> excited:) But I will repeat that I hope that you are considering
>> cross platform issues ...
> Yes we do. First we wanted to make it work. Then we should have kind
> of virtual packages that act as platforms or project level
When you talk about "virtual packages", I would say that a BaselineOf is
pretty much a "virtual package" already.

When it comes to cross-platform support there are several factors that
were built into Metacello from the very beginning:

   - it should be possible to USE a package on a different platform than
it was
      originally written for without modifying the package itself
   - it should be possible to SUBSTITUTE a platform-specific package with
      another platform-specific package without modifying either of the
packages
   - it should be possible to CHANGE the package dependencies based on
      platform-dependent requirements without modifying any of the packages

The key here is that if one needs to change a package to use it on a
different platform then you lose the ability to share source code.

The BaselineOf satisfies these requirements, because the "project meta
data" is separate from the package/source code and the BaselineOf itself
is cross-platform.

If you haven't thought about these issues from the very beginning, then
it may not be easy to shoe-horn support in after the fact ...

With all of that said, I really do love the idea of not having to
support Metacello anymore:) So I would like to see you succeed with your
effort!
>
>> Perhaps at this point in time, I'd like to read some code. Then I can
>> skip reading the paper and get a feel for how hard it will be to port
>> to GemStone:)
> I do not know where christophe save his code but it is be public.
I may not have time to read a paper ... but I would have time to read code:)

Dale

>
> A BaselineOf has a single baseline method and only the "pure"
> dependencies amongst the packages and projects needs to be expressed
> ... and these dependency specs are about "as small" as you can get ...
>>
Yes but we want them per package.
We do not work on that since more than one year by accident. I know what I meant was use of pragmas, chaining pragma, loading all the
configuration information (different baselines....).


I see well the reason. :)
The last point is the most tricky one when we have per package
dependencies. But I will let christophe answers.
>
> The BaselineOf satisfies these requirements, because the "project meta
> data" is separate from the package/source code and the BaselineOf
> itself is cross-platform.
>
> If you haven't thought about these issues from the very beginning,
> then it may not be easy to shoe-horn support in after the fact ...

I will let christophe answer.
>
> With all of that said, I really do love the idea of not having to
> support Metacello anymore:) So I would like to see you succeed with
> your effort!

Thanks. We will need help definitively.

>>> Perhaps at this point in time, I'd like to read some code. Then I
>>> can skip reading the paper and get a feel for how hard it will be to
>>> port to GemStone:)
>> I do not know where christophe save his code but it is be public.
> I may not have time to read a paper ... but I would have time to read
> code:)

:)

>
> Dale
>
>

Hi Dale,

Le 11 oct. 2015 à 18:42, Dale Henrichs a écrit :
Well, the point is not to replace metacello but to go towards a per package metadata description allowing some flexibility with the introduction of virtual packages.
This will allow, in a first time, to set up a package repository and more important, a web site on top of it. In a second time, I also want to enable more flexibility in expressing dependencies constraints (eg. > 2.0, 3.*, etc.). To achieve that, you need a very performant dependency solver and I would like to reuse linux ones (it has be done for ocaml by example) through CUDF (check http://mancoosi.org/).

For now, I implemented a simple solver for static dependency constraints (=1.2). I checked Metacello implementation and it looked to me that approaches are a bit too far to be able to reuse the whole code. For sure, it is not as robust as Metacello is, because you enhanced it for years.
What I want now, is to experiment (let's name it) Cargo Package Manager to see if it fits the needs. Pharo bootstrap is the first use case.


What I would like, is that, at the end, the dependency solver get out of Pharo and that we use already existing linux ones. What will stay into Pharo are packages metadata and the way to load a list of packages.