Do we kill the catalog?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Do we kill the catalog?

Stephane Ducasse-3
Hi guys

What do we do with it?
What alternatives?

Stef

Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

EstebanLM
why to kill it?
right now we do not have a replacement.

Esteban

> On 19 Apr 2018, at 08:42, Stephane Ducasse <[hidden email]> wrote:
>
> Hi guys
>
> What do we do with it?
> What alternatives?
>
> Stef
>


Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

EstebanLM


> On 19 Apr 2018, at 08:46, Esteban Lorenzano <[hidden email]> wrote:
>
> why to kill it?
> right now we do not have a replacement.

btw, I had this idea of

- using a STON spec instead a class (I think Dale has already something about it)
- using github as centralised repository to simplify the infrastructure, and to accept new projects as PRs :)

just… no time to implement it yet, but it should be fairly easy.

cheers,
Esteban

>
> Esteban
>
>> On 19 Apr 2018, at 08:42, Stephane Ducasse <[hidden email]> wrote:
>>
>> Hi guys
>>
>> What do we do with it?
>> What alternatives?
>>
>> Stef
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

Ben Coman
> 

> Esteban
> 
>> On 19 Apr 2018, at 08:42, Stephane Ducasse <[hidden email]> wrote:
>> 
>> Hi guys
>> 
>> What do we do with it?
>> What alternatives?
>> 
>> Stef
>> 
> 
 
On 19 April 2018 at 14:59, Esteban Lorenzano <[hidden email]> wrote:


> On 19 Apr 2018, at 08:46, Esteban Lorenzano <[hidden email]> wrote:
>
> why to kill it?
> right now we do not have a replacement.

btw, I had this idea of

- using a STON spec instead a class (I think Dale has already something about it)
- using github as centralised repository to simplify the infrastructure, and to accept new projects as PRs :)

just… no time to implement it yet, but it should be fairly easy.

cheers,
Esteban


This is a good idea.  The STON could be easily edited directly with github's web-based text editor
which would encourage third-parties to enhance the descriptions.  

Maybe good to publish it as a github pages, with a custom domain to shield against having to move away from github.

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

Torsten Bergmann
In reply to this post by Stephane Ducasse-3
Now today you had loading trouble with Smacc from Catalog ... and now directly want to
kill catalog. Wow!

Sometimes I have the impression that our community tries to reinvent itself each day
doing it differently (but not only better) instead of extending, improving and supporting
what we have have done before. Which sometimes is good ... but not always.

Thx
T.

> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr
> Von: "Stephane Ducasse" <[hidden email]>
> An: "Pharo Development List" <[hidden email]>
> Betreff: [Pharo-dev] Do we kill the catalog?
>
> Hi guys
>
> What do we do with it?
> What alternatives?
>
> Stef
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

Sven Van Caekenberghe-2
I also think that the catalog is important. If anything is wrong with it we should fix it.

The problem is that the catalog is never working well with the current unstable version of Pharo (today 7). Not all package developers take the trouble of checking/porting all the time, that is perfectly understandable.

Moving the catalog to GitHub with a STON meta description is a good idea, of course. All we need is a clean object representing the meta info, the rest comes for free.

> On 19 Apr 2018, at 10:38, Torsten Bergmann <[hidden email]> wrote:
>
> Now today you had loading trouble with Smacc from Catalog ... and now directly want to
> kill catalog. Wow!
>
> Sometimes I have the impression that our community tries to reinvent itself each day
> doing it differently (but not only better) instead of extending, improving and supporting
> what we have have done before. Which sometimes is good ... but not always.
>
> Thx
> T.
>
>> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr
>> Von: "Stephane Ducasse" <[hidden email]>
>> An: "Pharo Development List" <[hidden email]>
>> Betreff: [Pharo-dev] Do we kill the catalog?
>>
>> Hi guys
>>
>> What do we do with it?
>> What alternatives?
>>
>> Stef
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

Thierry Goubier
2018-04-19 10:57 GMT+02:00 Sven Van Caekenberghe <[hidden email]>:
> I also think that the catalog is important. If anything is wrong with it we should fix it.

I agree. Issues:

- The Catalog doesn't use Metacello, so things loaded via the catalog
are not registered properly (upgrades / conflicts)
- The Catalog mix multiple Meta repos and you never know, given a
configuration in multiple repos, which one the Catalog is giving you.
- The Catalog icons are ... non understandable.

> The problem is that the catalog is never working well with the current unstable version of Pharo (today 7). Not all package developers take the trouble of checking/porting all the time, that is perfectly understandable.

Never tried that one

> Moving the catalog to GitHub with a STON meta description is a good idea, of course. All we need is a clean object representing the meta info, the rest comes for free.

Maybe. I would like a automated way of extracting the json from a
baseline or configuration... to reduce the friction of using the
catalog.

Thierry

>> On 19 Apr 2018, at 10:38, Torsten Bergmann <[hidden email]> wrote:
>>
>> Now today you had loading trouble with Smacc from Catalog ... and now directly want to
>> kill catalog. Wow!
>>
>> Sometimes I have the impression that our community tries to reinvent itself each day
>> doing it differently (but not only better) instead of extending, improving and supporting
>> what we have have done before. Which sometimes is good ... but not always.
>>
>> Thx
>> T.
>>
>>> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr
>>> Von: "Stephane Ducasse" <[hidden email]>
>>> An: "Pharo Development List" <[hidden email]>
>>> Betreff: [Pharo-dev] Do we kill the catalog?
>>>
>>> Hi guys
>>>
>>> What do we do with it?
>>> What alternatives?
>>>
>>> Stef
>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

gcotelli
In reply to this post by Sven Van Caekenberghe-2
And please support the use of baselines. Nobody wants to also mantain a ConfigurationOf just for the catalog when using baselines.

On Thu, Apr 19, 2018, 05:58 Sven Van Caekenberghe <[hidden email]> wrote:
I also think that the catalog is important. If anything is wrong with it we should fix it.

The problem is that the catalog is never working well with the current unstable version of Pharo (today 7). Not all package developers take the trouble of checking/porting all the time, that is perfectly understandable.

Moving the catalog to GitHub with a STON meta description is a good idea, of course. All we need is a clean object representing the meta info, the rest comes for free.

> On 19 Apr 2018, at 10:38, Torsten Bergmann <[hidden email]> wrote:
>
> Now today you had loading trouble with Smacc from Catalog ... and now directly want to
> kill catalog. Wow!
>
> Sometimes I have the impression that our community tries to reinvent itself each day
> doing it differently (but not only better) instead of extending, improving and supporting
> what we have have done before. Which sometimes is good ... but not always.
>
> Thx
> T.
>
>> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr
>> Von: "Stephane Ducasse" <[hidden email]>
>> An: "Pharo Development List" <[hidden email]>
>> Betreff: [Pharo-dev] Do we kill the catalog?
>>
>> Hi guys
>>
>> What do we do with it?
>> What alternatives?
>>
>> Stef
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

EstebanLM


On 19 Apr 2018, at 11:25, Gabriel Cotelli <[hidden email]> wrote:

And please support the use of baselines. Nobody wants to also mantain a ConfigurationOf just for the catalog when using baselines.

that’s IMO the most important part we need to cover.

Esteban


On Thu, Apr 19, 2018, 05:58 Sven Van Caekenberghe <[hidden email]> wrote:
I also think that the catalog is important. If anything is wrong with it we should fix it.

The problem is that the catalog is never working well with the current unstable version of Pharo (today 7). Not all package developers take the trouble of checking/porting all the time, that is perfectly understandable.

Moving the catalog to GitHub with a STON meta description is a good idea, of course. All we need is a clean object representing the meta info, the rest comes for free.

> On 19 Apr 2018, at 10:38, Torsten Bergmann <[hidden email]> wrote:
>
> Now today you had loading trouble with Smacc from Catalog ... and now directly want to
> kill catalog. Wow!
>
> Sometimes I have the impression that our community tries to reinvent itself each day
> doing it differently (but not only better) instead of extending, improving and supporting
> what we have have done before. Which sometimes is good ... but not always.
>
> Thx
> T.
>
>> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr
>> Von: "Stephane Ducasse" <[hidden email]>
>> An: "Pharo Development List" <[hidden email]>
>> Betreff: [Pharo-dev] Do we kill the catalog?
>>
>> Hi guys
>>
>> What do we do with it?
>> What alternatives?
>>
>> Stef
>>
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

Stephan Eggermont-3
In reply to this post by gcotelli
Gabriel Cotelli <[hidden email]> wrote:
> And please support the use of baselines. Nobody wants to also mantain a
> ConfigurationOf just for the catalog when using baselines.

That sounds like a non-problem. One file that never needs to change. Let’s
solve the problems first

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

Peter Uhnak

What do we do with it?
What alternatives?
Stef

Is Cargo dead? I thought that was supposed to be the alternative.
 
That sounds like a non-problem. One file that never needs to change. Let’s
solve the problems first

How so? If I want for the catalog to load a specific version of Git(Hub) project, then I need to specify a tag. Which means every time I make a new release, I need to update the configuration. At least this is how I saw other people were addressing it.

Peter
Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

Stephane Ducasse-3
In reply to this post by Torsten Bergmann
Hi torsten

the wise shows the moon, the idiot sees his finger.

Stef


On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <[hidden email]> wrote:

> Now today you had loading trouble with Smacc from Catalog ... and now directly want to
> kill catalog. Wow!
>
> Sometimes I have the impression that our community tries to reinvent itself each day
> doing it differently (but not only better) instead of extending, improving and supporting
> what we have have done before. Which sometimes is good ... but not always.
>
> Thx
> T.
>
>> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr
>> Von: "Stephane Ducasse" <[hidden email]>
>> An: "Pharo Development List" <[hidden email]>
>> Betreff: [Pharo-dev] Do we kill the catalog?
>>
>> Hi guys
>>
>> What do we do with it?
>> What alternatives?
>>
>> Stef
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

Stephane Ducasse-3
In reply to this post by EstebanLM
The underlying questions (sorry for people that need subtitles) are:

- how do we have a central place to declare projects
    - right now in Smalltalkhub/list is a nice way to find projects
with the move to github
    we should get a central place

Christophe has been working on project repository and we should check
what he has.
@Christophe?

- how do we make sure that we can validated (I can load this version
of XMLParser in that version of Pharo)
-- in this version of Pharo what is the latest working version of this package

- if people do not maintain/add "configuration" into the catalog what
is the point?
-- How can we ease the participation to the catalog? Esteban I do not
care about the format.
Do you think that editing STON is easier than a class? I think that we
should have a button.
Look people do not care about posting their project into the repo.
May be we need a crawler?


@Peter no cargo is not dead now christophe cannot fix all the time the
PharoLauncher and make progress
on Cargo -> Pakbot
And yes I really want to have something that we can use soon.

- Needed immediate actions:
-- support baselineOf
-- how could we make sure that we can publish in multiple repo? (After
this is just a copy so I click on the package
and say copy to).

What else.
@thierry the story I do not use the catalog because the icons are not
understandable is not really good to me.


Stef


On Thu, Apr 19, 2018 at 8:46 AM, Esteban Lorenzano <[hidden email]> wrote:

> why to kill it?
> right now we do not have a replacement.
>
> Esteban
>
>> On 19 Apr 2018, at 08:42, Stephane Ducasse <[hidden email]> wrote:
>>
>> Hi guys
>>
>> What do we do with it?
>> What alternatives?
>>
>> Stef
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

Thierry Goubier
Le 20/04/2018 à 09:09, Stephane Ducasse a écrit :
> The underlying questions (sorry for people that need subtitles) are:
>
> - how do we have a central place to declare projects
>      - right now in Smalltalkhub/list is a nice way to find projects
> with the move to github
>      we should get a central place

One of the issues I have with the Catalog is that it made a mess of the
various MetaRrepo for Pharo... Showing in the end that the single place
one should put a ConfigurationOf for Pharo is the squeak meta repo.

That in addition the Catalog doesn't even use the best package
management we have at a given point is just salt rubbed in the wound.

> Christophe has been working on project repository and we should check
> what he has.
> @Christophe?
>
> - how do we make sure that we can validated (I can load this version
> of XMLParser in that version of Pharo)
> -- in this version of Pharo what is the latest working version of this package
>
> - if people do not maintain/add "configuration" into the catalog what
> is the point?
> -- How can we ease the participation to the catalog? Esteban I do not
> care about the format.
> Do you think that editing STON is easier than a class? I think that we
> should have a button.
> Look people do not care about posting their project into the repo.
> May be we need a crawler?

That would be an interesting concept, and maybe the right one, if the
alternative is updating a cryptic JSON format each time you commit
something in your project.

> @Peter no cargo is not dead now christophe cannot fix all the time the
> PharoLauncher and make progress
> on Cargo -> Pakbot
> And yes I really want to have something that we can use soon.
>
> - Needed immediate actions:
> -- support baselineOf
> -- how could we make sure that we can publish in multiple repo? (After
> this is just a copy so I click on the package
> and say copy to).
>
> What else.
> @thierry the story I do not use the catalog because the icons are not
> understandable is not really good to me.

As you wish. I know it belongs to one of these GUIs where I have to
spend 10 minutes to try to remember what the icons mean. But that's just me.

The key point to me is that the Catalog should reduce the friction it
creates, not that the Catalog has to be a perfect solution.

For example, do user-stories on it: how do one publish and updates a
project on the Catalog? What has one to do in CI to ensure a project is
validated ... Can the catalog just takes care of that part, if the
project has a correct setup (project has tests visible in the
configurationOf, catalog does the CI stuff of testing it upon each new
release of Pharo, even stable because Iceberg breaks stuff when updated
in Pharo 6.1, for example). Tags for Pharo versions are only granted if
project has been tested on CI by the Catalog for the current version
image you're in, for example.

We know how to explore and manipulate project specs already; look into
the GT tools for the code, and I also use a variant in my AltBrowser
when I sort all packages under the configuration or baseline they are
specified in.

In short, make it so that the Catalog is low friction and bring value to
both project maintainers and users.

Thierry

>
> Stef
>
>
> On Thu, Apr 19, 2018 at 8:46 AM, Esteban Lorenzano <[hidden email]> wrote:
>> why to kill it?
>> right now we do not have a replacement.
>>
>> Esteban
>>
>>> On 19 Apr 2018, at 08:42, Stephane Ducasse <[hidden email]> wrote:
>>>
>>> Hi guys
>>>
>>> What do we do with it?
>>> What alternatives?
>>>
>>> Stef
>>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

EstebanLM
In reply to this post by Stephane Ducasse-3
hi,

On 20 Apr 2018, at 09:09, Stephane Ducasse <[hidden email]> wrote:

The underlying questions (sorry for people that need subtitles) are:

- how do we have a central place to declare projects
   - right now in Smalltalkhub/list is a nice way to find projects
with the move to github
   we should get a central place

Christophe has been working on project repository and we should check
what he has.
@Christophe?

- how do we make sure that we can validated (I can load this version
of XMLParser in that version of Pharo)
-- in this version of Pharo what is the latest working version of this package

- if people do not maintain/add "configuration" into the catalog what
is the point?
-- How can we ease the participation to the catalog? Esteban I do not
care about the format.
Do you think that editing STON is easier than a class? I think that we
should have a button.

STON is easier because : 

- you do not need to load a package to know a project spec.
- you can edit it from outside, then participation is easier (in particular, people can add PRs and one can edit an STON file even in github site).

yet, yes… regardless the choice we should have a “publish” plugin in iceberg.

Look people do not care about posting their project into the repo.

but if they do not care to put their project in the cataog (whatever it is), is mostly sure they will not care to make it loadable (then validation is futile).

btw… this query will give us all projects on github that with filetree format: 

https://github.com/search?q=filename%3A.filetree+.package&type=Code&ref=advsearch (1531, but it will match each .filetree appearance so they are a lot less… )

and this one in tonel: 


we can put those links in pharo README to make them easier to find… but of course this does not covers bitbucket or gitlab (they may have a public search API, but I don’t know it)… best approach is to have a catalog.

May be we need a crawler?

we can, but we cannot know what is there in fact. 
btw… before we had sthub, but also ss, ss3 and others, so it was never clear about not published projects.


@Peter no cargo is not dead now christophe cannot fix all the time the
PharoLauncher and make progress
on Cargo -> Pakbot
And yes I really want to have something that we can use soon.

Cargo is orthogonal to the need of a centralised repository. 
Yes, its idea is to provide one… but we will need a central repo, always.

cheers,
Esteban


- Needed immediate actions:
-- support baselineOf
-- how could we make sure that we can publish in multiple repo? (After
this is just a copy so I click on the package
and say copy to).

What else.
@thierry the story I do not use the catalog because the icons are not
understandable is not really good to me.


Stef


On Thu, Apr 19, 2018 at 8:46 AM, Esteban Lorenzano <[hidden email]> wrote:
why to kill it?
right now we do not have a replacement.

Esteban

On 19 Apr 2018, at 08:42, Stephane Ducasse <[hidden email]> wrote:

Hi guys

What do we do with it?
What alternatives?

Stef





Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

EstebanLM
In reply to this post by Thierry Goubier


On 20 Apr 2018, at 11:01, Thierry Goubier <[hidden email]> wrote:

Le 20/04/2018 à 09:09, Stephane Ducasse a écrit :
The underlying questions (sorry for people that need subtitles) are:
- how do we have a central place to declare projects
    - right now in Smalltalkhub/list is a nice way to find projects
with the move to github
    we should get a central place

One of the issues I have with the Catalog is that it made a mess of the various MetaRrepo for Pharo... Showing in the end that the single place one should put a ConfigurationOf for Pharo is the squeak meta repo.

not really. 
if you put your project in the squeak meta repo it will not even be listed (is old stuff and we are not listing those).

the idea was to add a project in its corresponding development repo. But is an uncomfortable way, yes (and it was a patch, not meant to last)

That in addition the Catalog doesn't even use the best package management we have at a given point is just salt rubbed in the wound.

that’s a one method change. Instead: 

loadConfiguration 
Gofer it 
url: self repositoryUrl;
configurationOf: self name;
load

loadConfiguration 
Metacello new 
repository: self repositoryUrl;
configuration: self name;
load.

when I made catalog, Metacello usage was not so expanded. 
Yet… gofer will use metacello to load so, yes, it will use the best package management we have at the moment.


Christophe has been working on project repository and we should check
what he has.
@Christophe?
- how do we make sure that we can validated (I can load this version
of XMLParser in that version of Pharo)
-- in this version of Pharo what is the latest working version of this package
- if people do not maintain/add "configuration" into the catalog what
is the point?
-- How can we ease the participation to the catalog? Esteban I do not
care about the format.
Do you think that editing STON is easier than a class? I think that we
should have a button.
Look people do not care about posting their project into the repo.
May be we need a crawler?

That would be an interesting concept, and maybe the right one, if the alternative is updating a cryptic JSON format each time you commit something in your project.

very unlikely.
a spec made in STON you just have to modify it each time you do a release (which is exactly what you have to do now with configurations).

A crawler will not handle the need to publish a released version.

one STON file as I imagine would be something like: 

project {
“name” : "blah",
“lastVersion” : “v1.0.0",
“description” : “Some project description"
}

and maybe a couple more. How’s that cryptic?
maybe you are confusing things?


@Peter no cargo is not dead now christophe cannot fix all the time the
PharoLauncher and make progress
on Cargo -> Pakbot
And yes I really want to have something that we can use soon.
- Needed immediate actions:
-- support baselineOf
-- how could we make sure that we can publish in multiple repo? (After
this is just a copy so I click on the package
and say copy to).
What else.
@thierry the story I do not use the catalog because the icons are not
understandable is not really good to me.

As you wish. I know it belongs to one of these GUIs where I have to spend 10 minutes to try to remember what the icons mean. But that's just me.

The key point to me is that the Catalog should reduce the friction it creates, not that the Catalog has to be a perfect solution.

For example, do user-stories on it: how do one publish and updates a project on the Catalog? What has one to do in CI to ensure a project is validated ... Can the catalog just takes care of that part, if the project has a correct setup (project has tests visible in the configurationOf, catalog does the CI stuff of testing it upon each new release of Pharo, even stable because Iceberg breaks stuff when updated in Pharo 6.1, for example). Tags for Pharo versions are only granted if project has been tested on CI by the Catalog for the current version image you're in, for example.

We know how to explore and manipulate project specs already; look into the GT tools for the code, and I also use a variant in my AltBrowser when I sort all packages under the configuration or baseline they are specified in.

In short, make it so that the Catalog is low friction and bring value to both project maintainers and users.

Thierry

Stef
On Thu, Apr 19, 2018 at 8:46 AM, Esteban Lorenzano <[hidden email]> wrote:
why to kill it?
right now we do not have a replacement.

Esteban

On 19 Apr 2018, at 08:42, Stephane Ducasse <[hidden email]> wrote:

Hi guys

What do we do with it?
What alternatives?

Stef






Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

Thierry Goubier
Le 20/04/2018 à 11:44, Esteban Lorenzano a écrit :

>
>
>> On 20 Apr 2018, at 11:01, Thierry Goubier <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Le 20/04/2018 à 09:09, Stephane Ducasse a écrit :
>>> The underlying questions (sorry for people that need subtitles) are:
>>> - how do we have a central place to declare projects
>>>     - right now in Smalltalkhub/list is a nice way to find projects
>>> with the move to github
>>>     we should get a central place
>>
>> One of the issues I have with the Catalog is that it made a mess of
>> the various MetaRrepo for Pharo... Showing in the end that the single
>> place one should put a ConfigurationOf for Pharo is the squeak meta repo.
>
> not really.
> if you put your project in the squeak meta repo it will not even be
> listed (is old stuff and we are not listing those).
>
> the idea was to add a project in its corresponding development repo. But
> is an uncomfortable way, yes (and it was a patch, not meant to last)

And is it still in? Why then, on Pharo 7, is Catalog fetching SmaCC in
the Pharo5 meta repo?

>> That in addition the Catalog doesn't even use the best package
>> management we have at a given point is just salt rubbed in the wound.
>
> that’s a one method change. Instead:
>
> loadConfiguration
> Gofer it
> url: self repositoryUrl;
> configurationOf: self name;
> load
>
> loadConfiguration
> Metacello new
> repository: self repositoryUrl;
> configuration: self name;
> load.

Good point. Why wasn't it done?

I thought the choice of Gofer was on purpose, since other configurations
loaded in the image in the official build are done in the same way (i.e.
not Metacello).

On a more general point, this is a question to me. How does the Pharo
team, not using the project manager in its build process, intend to
properly define a project manager?

> when I made catalog, Metacello usage was not so expanded.
> Yet… gofer will use metacello to load so, yes, it will use the best
> package management we have at the moment.

Hum, for me Metacello uses Gofer for loading. Not the reverse. (i.e.
Metacello preps a spec, set up the repositories right including
downloading, then ask Gofer to execute). Easy proof: when loaded via
Metacello, Metacello registers the load (spec used, etc...); loaded via
Gofer, nothing (i.e. you don't even know which spec was used in the
configuration to load the packages).

Please feel free to disprove.

>>> Christophe has been working on project repository and we should check
>>> what he has.
>>> @Christophe?
>>> - how do we make sure that we can validated (I can load this version
>>> of XMLParser in that version of Pharo)
>>> -- in this version of Pharo what is the latest working version of
>>> this package
>>> - if people do not maintain/add "configuration" into the catalog what
>>> is the point?
>>> -- How can we ease the participation to the catalog? Esteban I do not
>>> care about the format.
>>> Do you think that editing STON is easier than a class? I think that we
>>> should have a button.
>>> Look people do not care about posting their project into the repo.
>>> May be we need a crawler?
>>
>> That would be an interesting concept, and maybe the right one, if the
>> alternative is updating a cryptic JSON format each time you commit
>> something in your project.
>
> very unlikely.
> a spec made in STON you just have to modify it each time you do a
> release (which is exactly what you have to do now with configurations).
>
> A crawler will not handle the need to publish a released version.
>
> one STON file as I imagine would be something like:
>
> project {
> “name” : "blah",
> “url” : "http://github.com/someone/blah",
> “lastVersion” : “v1.0.0",
> “description” : “Some project description"
> }

> and maybe a couple more. How’s that cryptic?
> maybe you are confusing things?

No.

Just write that ston now for the current state of OSProcess (with all
versions and platforms supported).

Or write that ston for a project that has stable branches for all pharo
versions, from say 1.3 to now.

But, in a way, please do the way you like, and, well, a few years down
the line, we're back at the same situation as now.

Not that I wish it, but I can see when someone is solving a problem with
yet another way of having the problem.

Thierry

>>> @Peter no cargo is not dead now christophe cannot fix all the time the
>>> PharoLauncher and make progress
>>> on Cargo -> Pakbot
>>> And yes I really want to have something that we can use soon.
>>> - Needed immediate actions:
>>> -- support baselineOf
>>> -- how could we make sure that we can publish in multiple repo? (After
>>> this is just a copy so I click on the package
>>> and say copy to).
>>> What else.
>>> @thierry the story I do not use the catalog because the icons are not
>>> understandable is not really good to me.
>>
>> As you wish. I know it belongs to one of these GUIs where I have to
>> spend 10 minutes to try to remember what the icons mean. But that's
>> just me.
>>
>> The key point to me is that the Catalog should reduce the friction it
>> creates, not that the Catalog has to be a perfect solution.
>>
>> For example, do user-stories on it: how do one publish and updates a
>> project on the Catalog? What has one to do in CI to ensure a project
>> is validated ... Can the catalog just takes care of that part, if the
>> project has a correct setup (project has tests visible in the
>> configurationOf, catalog does the CI stuff of testing it upon each new
>> release of Pharo, even stable because Iceberg breaks stuff when
>> updated in Pharo 6.1, for example). Tags for Pharo versions are only
>> granted if project has been tested on CI by the Catalog for the
>> current version image you're in, for example.
>>
>> We know how to explore and manipulate project specs already; look into
>> the GT tools for the code, and I also use a variant in my AltBrowser
>> when I sort all packages under the configuration or baseline they are
>> specified in.
>>
>> In short, make it so that the Catalog is low friction and bring value
>> to both project maintainers and users.
>>
>> Thierry
>>
>>> Stef
>>> On Thu, Apr 19, 2018 at 8:46 AM, Esteban Lorenzano
>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>> why to kill it?
>>>> right now we do not have a replacement.
>>>>
>>>> Esteban
>>>>
>>>>> On 19 Apr 2018, at 08:42, Stephane Ducasse <[hidden email]
>>>>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>> Hi guys
>>>>>
>>>>> What do we do with it?
>>>>> What alternatives?
>>>>>
>>>>> Stef
>>>>>
>>>>
>>>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

CyrilFerlicot
In reply to this post by EstebanLM
Le 20/04/2018 à 11:44, Esteban Lorenzano a écrit :

>
>
>> On 20 Apr 2018, at 11:01, Thierry Goubier <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Le 20/04/2018 à 09:09, Stephane Ducasse a écrit :
>>> The underlying questions (sorry for people that need subtitles) are:
>>> - how do we have a central place to declare projects
>>>     - right now in Smalltalkhub/list is a nice way to find projects
>>> with the move to github
>>>     we should get a central place
>>
>> One of the issues I have with the Catalog is that it made a mess of
>> the various MetaRrepo for Pharo... Showing in the end that the single
>> place one should put a ConfigurationOf for Pharo is the squeak meta repo.
>
> not really. 
> if you put your project in the squeak meta repo it will not even be
> listed (is old stuff and we are not listing those).
>
> the idea was to add a project in its corresponding development repo. But
> is an uncomfortable way, yes (and it was a patch, not meant to last)
>
>> That in addition the Catalog doesn't even use the best package
>> management we have at a given point is just salt rubbed in the wound.
>
> that’s a one method change. Instead: 
>
> loadConfiguration 
> Gofer it 
> url: self repositoryUrl;
> configurationOf: self name;
> load
>
> loadConfiguration 
> Metacello new 
> repository: self repositoryUrl;
> configuration: self name;
> load.
>
> when I made catalog, Metacello usage was not so expanded. 
> Yet… gofer will use metacello to load so, yes, it will use the best
> package management we have at the moment.
>
Hi,

Except if it changed recently, Gofer does not use Metacello behind.

At Synectique when I tried to clean all our configurations because it
was really hard to update them, I found some problems in the
configurations but the projects were loading. The reasons was that we
used Gofer and the bugs of gofer compensated the problems in the
configurations. After switching to Metacello the projects did not load
anymore and I needed to fix the configurations to make them clean.

So, if it worked with Gofer but not Metacello, I doubt Gofer use Metacello.

>
> very unlikely.
> a spec made in STON you just have to modify it each time you do a
> release (which is exactly what you have to do now with configurations).
>
> A crawler will not handle the need to publish a released version.
>
> one STON file as I imagine would be something like: 
>
> project {
> “name” : "blah",
> “url” : "http://github.com/someone/blah",
> “lastVersion” : “v1.0.0",
> “description” : “Some project description"
> }
>
> and maybe a couple more. How’s that cryptic?
> maybe you are confusing things?
>
>

--
Cyril Ferlicot
https://ferlicot.fr


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

Sean P. DeNigris
Administrator
In reply to this post by Thierry Goubier
Thierry Goubier wrote
> how do one publish and updates a project on the Catalog? What has one to
> do in CI to ensure a project is validated

To get started, it might be helpful to provide some snippets that people can
insert into their own project's CI for this. I'll do a spike when I have a
moment…



-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Do we kill the catalog?

EstebanLM
In reply to this post by Thierry Goubier


On 20 Apr 2018, at 12:20, Thierry Goubier <[hidden email]> wrote:

Le 20/04/2018 à 11:44, Esteban Lorenzano a écrit :
On 20 Apr 2018, at 11:01, Thierry Goubier <[hidden email] <[hidden email]>> wrote:

Le 20/04/2018 à 09:09, Stephane Ducasse a écrit :
The underlying questions (sorry for people that need subtitles) are:
- how do we have a central place to declare projects
    - right now in Smalltalkhub/list is a nice way to find projects
with the move to github
    we should get a central place

One of the issues I have with the Catalog is that it made a mess of the various MetaRrepo for Pharo... Showing in the end that the single place one should put a ConfigurationOf for Pharo is the squeak meta repo.
not really.
if you put your project in the squeak meta repo it will not even be listed (is old stuff and we are not listing those).
the idea was to add a project in its corresponding development repo. But is an uncomfortable way, yes (and it was a patch, not meant to last)

And is it still in? Why then, on Pharo 7, is Catalog fetching SmaCC in the Pharo5 meta repo?

That in addition the Catalog doesn't even use the best package management we have at a given point is just salt rubbed in the wound.
that’s a one method change. Instead:
loadConfiguration
Gofer it
url: self repositoryUrl;
configurationOf: self name;
load
loadConfiguration
Metacello new
repository: self repositoryUrl;
configuration: self name;
load.

Good point. Why wasn't it done?

I thought the choice of Gofer was on purpose, since other configurations loaded in the image in the official build are done in the same way (i.e. not Metacello).

not true. 
It is not possible to load configurations without metacello.


On a more general point, this is a question to me. How does the Pharo team, not using the project manager in its build process, intend to properly define a project manager?

What are you calling “the project manager” ?


when I made catalog, Metacello usage was not so expanded.
Yet… gofer will use metacello to load so, yes, it will use the best package management we have at the moment.

Hum, for me Metacello uses Gofer for loading. Not the reverse. (i.e. Metacello preps a spec, set up the repositories right including downloading, then ask Gofer to execute). Easy proof: when loaded via Metacello, Metacello registers the load (spec used, etc...); loaded via Gofer, nothing (i.e. you don't even know which spec was used in the configuration to load the packages).

Please feel free to disprove.

Gofer uses metacello to load configurations. Metacello then uses Gofer to load packages. If through Gofer there is not registration, then is a bug of Metacello.
It is not possible for Pharo to load configurations without metacello.


Christophe has been working on project repository and we should check
what he has.
@Christophe?
- how do we make sure that we can validated (I can load this version
of XMLParser in that version of Pharo)
-- in this version of Pharo what is the latest working version of this package
- if people do not maintain/add "configuration" into the catalog what
is the point?
-- How can we ease the participation to the catalog? Esteban I do not
care about the format.
Do you think that editing STON is easier than a class? I think that we
should have a button.
Look people do not care about posting their project into the repo.
May be we need a crawler?

That would be an interesting concept, and maybe the right one, if the alternative is updating a cryptic JSON format each time you commit something in your project.
very unlikely.
a spec made in STON you just have to modify it each time you do a release (which is exactly what you have to do now with configurations).
A crawler will not handle the need to publish a released version.
one STON file as I imagine would be something like:
project {
“name” : "blah",
“url” : "http://github.com/someone/blah",
“lastVersion” : “v1.0.0",
“description” : “Some project description"
}

and maybe a couple more. How’s that cryptic?
maybe you are confusing things?

No.

Just write that ston now for the current state of OSProcess (with all versions and platforms supported).

yes, you are confusing things.
you do not need to explicit anything of that :)

- you describe a project location and a version. You do not describe the project itself: that’s the work of a baseline. 
- You also do not describe a version: That’s a tag (or a branch). The baseline (or baseline spec) in that branch describes the project in that moment. 

when you release, you say: hey, I’m giving you version X. Not more than that.


Or write that ston for a project that has stable branches for all pharo versions, from say 1.3 to now.

why?
let’s suppose you want compatibility: 

project {
“name” : "blah",
“versions” : {
#pharoLatest : ‘v7.0.0’;
#pharo6 : ‘v6.0.0’;
#pharo5 : ‘v5.0.0’;
#pharo4 : ‘v4.0.0’;
#pharo3 : ‘v3.0.0’;
#’gemstone3.30' : ‘v5.0.0’;
},
“description” : “Some project description"
}

again… what’s cryptic or complicated there, more than what you already do in a baseline? Why is clearer in a baseline?

But, in a way, please do the way you like, and, well, a few years down the line, we're back at the same situation as now.

Not that I wish it, but I can see when someone is solving a problem with yet another way of having the problem.

Describing a project in a way that can be managed without needing to load a package into the image is another problem. A problem that is present since a lot and Dale and me talked a lot of times on how to fix it.
Having a STON with a spec of the baseline is an easy and clear way.
but that has nothing to do with storing releases in a discoverable way.

right now you need to create a new version on a configuration and copy that package into a metacello repository. 
if you want to make them appear properly in catalog, you also need to implement some “cryptic” methods nobody does it right the first time.

Esteban


Thierry

@Peter no cargo is not dead now christophe cannot fix all the time the
PharoLauncher and make progress
on Cargo -> Pakbot
And yes I really want to have something that we can use soon.
- Needed immediate actions:
-- support baselineOf
-- how could we make sure that we can publish in multiple repo? (After
this is just a copy so I click on the package
and say copy to).
What else.
@thierry the story I do not use the catalog because the icons are not
understandable is not really good to me.

As you wish. I know it belongs to one of these GUIs where I have to spend 10 minutes to try to remember what the icons mean. But that's just me.

The key point to me is that the Catalog should reduce the friction it creates, not that the Catalog has to be a perfect solution.

For example, do user-stories on it: how do one publish and updates a project on the Catalog? What has one to do in CI to ensure a project is validated ... Can the catalog just takes care of that part, if the project has a correct setup (project has tests visible in the configurationOf, catalog does the CI stuff of testing it upon each new release of Pharo, even stable because Iceberg breaks stuff when updated in Pharo 6.1, for example). Tags for Pharo versions are only granted if project has been tested on CI by the Catalog for the current version image you're in, for example.

We know how to explore and manipulate project specs already; look into the GT tools for the code, and I also use a variant in my AltBrowser when I sort all packages under the configuration or baseline they are specified in.

In short, make it so that the Catalog is low friction and bring value to both project maintainers and users.

Thierry

Stef
On Thu, Apr 19, 2018 at 8:46 AM, Esteban Lorenzano <[hidden email] <[hidden email]>> wrote:
why to kill it?
right now we do not have a replacement.

Esteban

On 19 Apr 2018, at 08:42, Stephane Ducasse <[hidden email] <[hidden email]>> wrote:

Hi guys

What do we do with it?
What alternatives?

Stef








123