On 19 Apr 2018, at 08:46, Esteban Lorenzano <estebanlm@gmail.com> 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 <stepharo.self@gmail.com> wrote:
Hi guys
What do we do with it? What alternatives?
Stef
Esteban
On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self@gmail.com>
wrote:
Hi guys
What do we do with it? What alternatives?
Stef
On 19 April 2018 at 14:59, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 19 Apr 2018, at 08:46, Esteban Lorenzano <estebanlm@gmail.com> 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. https://help.github.com/articles/about-supported-custom-domains/#custom-subd... cheers -ben
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 <estebanlm@gmail.com> wrote:
why to kill it? right now we do not have a replacement.
Esteban
On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi guys
What do we do with it? What alternatives?
Stef
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 <estebanlm@gmail.com> wrote:
why to kill it? right now we do not have a replacement.
Esteban
On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi guys
What do we do with it? What alternatives?
Stef
On 20 Apr 2018, at 11:01, Thierry Goubier <thierry.goubier@gmail.com> 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", âurlâ : "http://github.com/someone/blah <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?
@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 <estebanlm@gmail.com> wrote:
why to kill it? right now we do not have a replacement.
Esteban
On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi guys
What do we do with it? What alternatives?
Stef
Le 20/04/2018 à 11:44, Esteban Lorenzano a écrit :
On 20 Apr 2018, at 11:01, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> 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 <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
why to kill it? right now we do not have a replacement.
Esteban
On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote:
Hi guys
What do we do with it? What alternatives?
Stef
On 20 Apr 2018, at 12:20, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 20/04/2018 à 11:44, Esteban Lorenzano a écrit :
On 20 Apr 2018, at 11:01, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> 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", âurlâ : "http://github.com/someone/blah <http://github.com/someone/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 <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
why to kill it? right now we do not have a replacement.
Esteban
On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote:
Hi guys
What do we do with it? What alternatives?
Stef
Thierry Goubier <thierry.goubier@gmail.com> wrote:
No
+1
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.
Indeed. Stephan
Le 20/04/2018 à 11:44, Esteban Lorenzano a écrit :
On 20 Apr 2018, at 11:01, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> 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
On 20 Apr 2018, at 12:42, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Le 20/04/2018 à 11:44, Esteban Lorenzano a écrit :
On 20 Apr 2018, at 11:01, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> 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.
there is no way of loading a configuration/baseline without metacello. Esteban
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
Hi all, IMHO, the problem is not metacello or gofer but the fact that the catalog uses the old Metacello API: i.e., Gofer new repository: 'zzz'; configurationOf: 'XXX'; load. (ConfigurationOfXXX project version: #YYY) load instead of the *new* Metacello API Metacello new repository: 'zzz' configurationOf: 'XXX' loadVersion: #'YYY' On Fri, Apr 20, 2018 at 3:34 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 20 Apr 2018, at 12:42, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Le 20/04/2018 à 11:44, Esteban Lorenzano a écrit :
On 20 Apr 2018, at 11:01, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> 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.
there is no way of loading a configuration/baseline without metacello.
Esteban
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
-- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
On ven. 20 avr. 2018 at 15:53, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi all,
IMHO, the problem is not metacello or gofer but the fact that the catalog uses the old Metacello API: i.e.,
Gofer new repository: 'zzz'; configurationOf: 'XXX'; load. (ConfigurationOfXXX project version: #YYY) load
instead of the *new* Metacello API
Metacello new repository: 'zzz' configurationOf: 'XXX' loadVersion: #'YYY'
This is exactly what I had in mind for "loading via gofer" vs "loading via Metacello" since I don't know the implementation behind.
--
Guille Polito
Research Engineer
Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>*
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13
-- Cyril Ferlicot https://ferlicot.fr
Hi guille should we open an issue and update the catalog? Stef On Fri, Apr 20, 2018 at 3:53 PM, Guillermo Polito <guillermopolito@gmail.com
wrote:
Hi all,
IMHO, the problem is not metacello or gofer but the fact that the catalog uses the old Metacello API: i.e.,
Gofer new repository: 'zzz'; configurationOf: 'XXX'; load. (ConfigurationOfXXX project version: #YYY) load
instead of the *new* Metacello API
Metacello new repository: 'zzz' configurationOf: 'XXX' loadVersion: #'YYY'
On Fri, Apr 20, 2018 at 3:34 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 20 Apr 2018, at 12:42, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Le 20/04/2018 à 11:44, Esteban Lorenzano a écrit :
On 20 Apr 2018, at 11:01, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> 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.
there is no way of loading a configuration/baseline without metacello.
Esteban
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
--
Guille Polito
Research Engineer
Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>*
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13
So what are the key "immediate" action to improve the situation - Support for Baseline (no idea what it means) - Use Metacello API. Metacello new repository: 'zzz' configurationOf: 'XXX' loadVersion: #'YYY' - What else? Stef On Fri, Apr 20, 2018 at 7:27 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi guille
should we open an issue and update the catalog?
Stef
On Fri, Apr 20, 2018 at 3:53 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:
Hi all,
IMHO, the problem is not metacello or gofer but the fact that the catalog uses the old Metacello API: i.e.,
Gofer new repository: 'zzz'; configurationOf: 'XXX'; load. (ConfigurationOfXXX project version: #YYY) load
instead of the *new* Metacello API
Metacello new repository: 'zzz' configurationOf: 'XXX' loadVersion: #'YYY'
On Fri, Apr 20, 2018 at 3:34 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 20 Apr 2018, at 12:42, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Le 20/04/2018 à 11:44, Esteban Lorenzano a écrit :
On 20 Apr 2018, at 11:01, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> 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.
there is no way of loading a configuration/baseline without metacello.
Esteban
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
--
Guille Polito
Research Engineer
Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>*
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13
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
Thierry May be you are nervous these days. But try to relax and get a positive mindset. This is not perfect but it is there. You know that we are all full and even more. So just criticizing is not productive.
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.
If you find that funny it is not. The point of having multiple repo was to make sure that contrary to the old squeak experience projects would load.
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.
I do not get what you mean but do not reply. I do not think that it will be interested. You are in a ranting mode and it deos not help.
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.
Come on. There are fly by help
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.
I have a long todo list too. We just did not get the resources for it. Let us face it.
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 <estebanlm@gmail.com> wrote:
why to kill it? right now we do not have a replacement.
Esteban
On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi guys
What do we do with it? What alternatives?
Stef
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. Yes, but it already has STON manfiests to define the projects (project-metadata.ston). So why not use/extend the same file. Peter On Fri, Apr 20, 2018 at 7:23 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Thierry
May be you are nervous these days. But try to relax and get a positive mindset. This is not perfect but it is there. You know that we are all full and even more. So just criticizing is not productive.
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.
If you find that funny it is not. The point of having multiple repo was to make sure that contrary to the old squeak experience projects would load.
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.
I do not get what you mean but do not reply. I do not think that it will be interested. You are in a ranting mode and it deos not help.
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.
Come on. There are fly by help
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.
I have a long todo list too. We just did not get the resources for it. Let us face it.
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 <estebanlm@gmail.com
wrote:
why to kill it? right now we do not have a replacement.
Esteban
On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi guys
What do we do with it? What alternatives?
Stef
On Fri, Apr 20, 2018 at 7:28 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:
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.
Yes, but it already has STON manfiests to define the projects (project-metadata.ston). So why not use/extend the same file.
+1
Peter
On Fri, Apr 20, 2018 at 7:23 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Thierry
May be you are nervous these days. But try to relax and get a positive mindset. This is not perfect but it is there. You know that we are all full and even more. So just criticizing is not productive.
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.
If you find that funny it is not. The point of having multiple repo was to make sure that contrary to the old squeak experience projects would load.
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.
I do not get what you mean but do not reply. I do not think that it will be interested. You are in a ranting mode and it deos not help.
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.
Come on. There are fly by help
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.
I have a long todo list too. We just did not get the resources for it. Let us face it.
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 <estebanlm@gmail.com> wrote:
why to kill it? right now we do not have a replacement.
Esteban
On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi guys
What do we do with it? What alternatives?
Stef
hi,
On 20 Apr 2018, at 09:09, Stephane Ducasse <stepharo.self@gmail.com> 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=advs... <https://github.com/search?q=filename:.filetree+.package&type=Code&ref=advsea...> (1531, but it will match each .filetree appearance so they are a lot less⦠) and this one in tonel: https://github.com/search?q=filename%3A.properties+tonel&type=Code&ref=advse... <https://github.com/search?q=filename:.properties+tonel&type=Code&ref=advsear...> (just 49 for now :(, but unique repositories :P) 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 <estebanlm@gmail.com> wrote:
why to kill it? right now we do not have a replacement.
Esteban
On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi guys
What do we do with it? What alternatives?
Stef
Hi Stef, 2018-04-20 7:09 GMT+00:00 Stephane Ducasse <stepharo.self@gmail.com>:
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?
That's why I try to do with PI https://github.com/hernanmd/pi It's 100% command-line, which I know smalltalkers don't love. However after working with Python, R, Perl, etc. I saw the world expects a pretty standard package installation pattern. I feel (outsider) people really don't care if there is a Catalog, StHub, PepeHub. Please everyone feel free to fork and add/fix anything you need from PI. Hernan
@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 <estebanlm@gmail.com> wrote:
why to kill it? right now we do not have a replacement.
Esteban
On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi guys
What do we do with it? What alternatives?
Stef
On 20/04/2018 14:42, Hernán Morales Durand wrote:
Hi Stef,
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's why I try to do with PI https://github.com/hernanmd/pi
It's 100% command-line, which I know smalltalkers don't love.
However after working with Python, R, Perl, etc. I saw the world expects a pretty standard package installation pattern.
+1
I feel (outsider) people really don't care if there is a Catalog, StHub, PepeHub.
We have the right (and probably the reasons) to do things "our way", but it shouldn't surprise us if outsiders and newcomers reject that way because it feels weird, even if is better than what they're used to. Regards, -- Esteban A. Maringolo
That's why I try to do with PI https://github.com/hernanmd/pi
It's 100% command-line, which I know smalltalkers don't love.
do not draw conclusions like that.
However after working with Python, R, Perl, etc. I saw the world expects a pretty standard package installation pattern. I feel (outsider) people really don't care if there is a Catalog, StHub, PepeHub.
This is not for the others this is for US. And We plan to have a command line interface for the launcher and also for pakbot.
Please everyone feel free to fork and add/fix anything you need from PI.
Hernan
@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 <estebanlm@gmail.com> wrote:
why to kill it? right now we do not have a replacement.
Esteban
On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi guys
What do we do with it? What alternatives?
Stef
El vie., 20 abr. 2018 4:39 p. m., Stephane Ducasse <stepharo.self@gmail.com> escribió:
That's why I try to do with PI https://github.com/hernanmd/pi
It's 100% command-line, which I know smalltalkers don't love.
do not draw conclusions like that.
However after working with Python, R, Perl, etc. I saw the world expects a pretty standard package installation pattern. I feel (outsider) people really don't care if there is a Catalog, StHub, PepeHub.
This is not for the others this is for US. And We plan to have a command line interface for the launcher and also for pakbot.
What is pakbot? Let me know if we can join efforts, it would be sad to see unnecessary duplication.
Please everyone feel free to fork and add/fix anything you need from PI.
Hernan
@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 <estebanlm@gmail.com>
wrote:
why to kill it? right now we do not have a replacement.
Esteban
On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi guys
What do we do with it? What alternatives?
Stef
>> >> This is not for the others this is for US. >> And We plan to have a command line interface for the launcher and >> also for pakbot. > > > What is pakbot? the new name of Cargo pakbot = paquebot in french = cargo in english :) > > Let me know if we can join efforts, it would be sad to see unnecessary > duplication. tx that you ask. @Christophe what would be case? >From my side, What we would like to have - is to use Clap the new command handler system (may be Clap needs another pass but we should push it) - if clap is not ready either fix it or use the old command line handler - add command line support to the launcher to download and install image and also packages. Stef
On sam. 21 avr. 2018 at 08:45, Stephane Ducasse <stepharo.self@gmail.com> wrote:
the new name of Cargo pakbot = paquebot in french = cargo in english :)
Just for the record: https://github.com/demarey/cargo/issues/32 To explain the name change.
tx that you ask. @Christophe what would be case?
From my side, What we would like to have - is to use Clap the new command handler system (may be Clap needs another pass but we should push it) - if clap is not ready either fix it or use the old command line handler - add command line support to the launcher to download and install image and also packages.
Stef
-- Cyril Ferlicot https://ferlicot.fr
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" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Do we kill the catalog?
Hi guys
What do we do with it? What alternatives?
Stef
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 <astares@gmx.de> 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" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Do we kill the catalog?
Hi guys
What do we do with it? What alternatives?
Stef
2018-04-19 10:57 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>:
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 <astares@gmx.de> 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" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Do we kill the catalog?
Hi guys
What do we do with it? What alternatives?
Stef
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 <sven@stfx.eu> 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 <astares@gmx.de> 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" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Do we kill the catalog?
Hi guys
What do we do with it? What alternatives?
Stef
On 19 Apr 2018, at 11:25, Gabriel Cotelli <g.cotelli@gmail.com> 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 <sven@stfx.eu <mailto:sven@stfx.eu>> 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 <astares@gmx.de <mailto:astares@gmx.de>> 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" <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> An: "Pharo Development List" <pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> Betreff: [Pharo-dev] Do we kill the catalog?
Hi guys
What do we do with it? What alternatives?
Stef
Gabriel Cotelli <g.cotelli@gmail.com> 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
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
Hi torsten the wise shows the moon, the idiot sees his finger. Stef On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares@gmx.de> 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" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Do we kill the catalog?
Hi guys
What do we do with it? What alternatives?
Stef
Even there is no learning from the past - it's deja vu all over again...
Gesendet: Freitag, 20. April 2018 um 08:53 Uhr Von: "Stephane Ducasse" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Do we kill the catalog?
Hi torsten
the wise shows the moon, the idiot sees his finger.
Stef
On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares@gmx.de> 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" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Do we kill the catalog?
Hi guys
What do we do with it? What alternatives?
Stef
Torsten Sometimes you should relax. Because if you remember I pushed the catalog (in fact I love it and we need a much more powerful one) and I even improved it. I made it better to automatically add MC repositories. Of course Thierry is exagerating. Now we should fix or remove it. Simple no? Now you can rant in your corner thinking that I'm asshole. This is ok for me. Stef On Sat, Apr 21, 2018 at 3:06 PM, Torsten Bergmann <astares@gmx.de> wrote:
Even there is no learning from the past - it's deja vu all over again...
Gesendet: Freitag, 20. April 2018 um 08:53 Uhr Von: "Stephane Ducasse" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Do we kill the catalog?
Hi torsten
the wise shows the moon, the idiot sees his finger.
Stef
On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares@gmx.de> 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" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Do we kill the catalog?
Hi guys
What do we do with it? What alternatives?
Stef
Hi Stef, do not worry - I'm fully relaxed. It is you - who suggested to kill the catalog - without having or proposing a suitable alternative yet. If you want to route the thread to talking about "idiots" and "assholes" you go offtopic and I guess I have nothing more to contribute to the discussion. If it was not clear from my writing: I only expressed my wish that we should better improve it instead of killing it. That's all. Because anytime we have a better idea we get more disruptive in what we provide ... and this leads to the unfortunate situation: - that we replace our own stuff with newer ones again and again (which can but must not be good as things get more diverse and complicated over time) - that users have to know how things historically have been progressed to find its way through Pharo (including the terms and tools we use) I would not see this as a rant - but rather a true effect we can spot on many places in our ecosystem already. Long story short: I would vote for the "fix" if the sole other option is to "remove". Bye T.
Gesendet: Samstag, 21. April 2018 um 15:31 Uhr Von: "Stephane Ducasse" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Do we kill the catalog?
Torsten
Sometimes you should relax. Because if you remember I pushed the catalog (in fact I love it and we need a much more powerful one) and I even improved it. I made it better to automatically add MC repositories. Of course Thierry is exagerating.
Now we should fix or remove it. Simple no?
Now you can rant in your corner thinking that I'm asshole. This is ok for me.
Stef
On Sat, Apr 21, 2018 at 3:06 PM, Torsten Bergmann <astares@gmx.de> wrote:
Even there is no learning from the past - it's deja vu all over again...
Gesendet: Freitag, 20. April 2018 um 08:53 Uhr Von: "Stephane Ducasse" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Do we kill the catalog?
Hi torsten
the wise shows the moon, the idiot sees his finger.
Stef
On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares@gmx.de> 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" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Do we kill the catalog?
Hi guys
What do we do with it? What alternatives?
Stef
+1. Replacing is sometimes necessary (Sven's stream work is an obvious example), but I don't see why Nautilus had to be junked rather than gradually evolved into Calypso. And I don't see why the catalog can't be gradually evolved into something better. Killing it off would be discouraging to the users who went through the trouble of adding #catalogXXX methods to their configs and publishing them to the meta repos. Why would they bother adopting whatever replaces the catalog if they think it will just get killed off too? ___ montyos.wordpress.com
Sent: Sunday, April 22, 2018 at 9:29 AM From: "Torsten Bergmann" <astares@gmx.de> To: pharo-dev@lists.pharo.org Cc: "Pharo Development List" <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] Do we kill the catalog?
Hi Stef,
do not worry - I'm fully relaxed. It is you - who suggested to kill the catalog - without having or proposing a suitable alternative yet. If you want to route the thread to talking about "idiots" and "assholes" you go offtopic and I guess I have nothing more to contribute to the discussion.
If it was not clear from my writing: I only expressed my wish that we should better improve it instead of killing it. That's all.
Because anytime we have a better idea we get more disruptive in what we provide ... and this leads to the unfortunate situation:
- that we replace our own stuff with newer ones again and again (which can but must not be good as things get more diverse and complicated over time) - that users have to know how things historically have been progressed to find its way through Pharo (including the terms and tools we use)
I would not see this as a rant - but rather a true effect we can spot on many places in our ecosystem already.
Long story short: I would vote for the "fix" if the sole other option is to "remove".
Bye T.
Gesendet: Samstag, 21. April 2018 um 15:31 Uhr Von: "Stephane Ducasse" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Do we kill the catalog?
Torsten
Sometimes you should relax. Because if you remember I pushed the catalog (in fact I love it and we need a much more powerful one) and I even improved it. I made it better to automatically add MC repositories. Of course Thierry is exagerating.
Now we should fix or remove it. Simple no?
Now you can rant in your corner thinking that I'm asshole. This is ok for me.
Stef
On Sat, Apr 21, 2018 at 3:06 PM, Torsten Bergmann <astares@gmx.de> wrote:
Even there is no learning from the past - it's deja vu all over again...
Gesendet: Freitag, 20. April 2018 um 08:53 Uhr Von: "Stephane Ducasse" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Do we kill the catalog?
Hi torsten
the wise shows the moon, the idiot sees his finger.
Stef
On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares@gmx.de> 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" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Do we kill the catalog?
Hi guys
What do we do with it? What alternatives?
Stef
On 24 Apr 2018, at 00:49, monty <monty2@programmer.net> wrote:
+1.
Replacing is sometimes necessary (Sven's stream work is an obvious example), but I don't see why Nautilus had to be junked rather than gradually evolved into Calypso. And I don't see why the catalog can't be gradually evolved into something better. Killing it off would be discouraging to the users who went through the trouble of adding #catalogXXX methods to their configs and publishing them to the meta repos. Why would they bother adopting whatever replaces the catalog if they think it will just get killed off too?
___ montyos.wordpress.com
Nice blog, BTW! Your XML work is much appreciated.
Sent: Sunday, April 22, 2018 at 9:29 AM From: "Torsten Bergmann" <astares@gmx.de> To: pharo-dev@lists.pharo.org Cc: "Pharo Development List" <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] Do we kill the catalog?
Hi Stef,
do not worry - I'm fully relaxed. It is you - who suggested to kill the catalog - without having or proposing a suitable alternative yet. If you want to route the thread to talking about "idiots" and "assholes" you go offtopic and I guess I have nothing more to contribute to the discussion.
If it was not clear from my writing: I only expressed my wish that we should better improve it instead of killing it. That's all.
Because anytime we have a better idea we get more disruptive in what we provide ... and this leads to the unfortunate situation:
- that we replace our own stuff with newer ones again and again (which can but must not be good as things get more diverse and complicated over time) - that users have to know how things historically have been progressed to find its way through Pharo (including the terms and tools we use)
I would not see this as a rant - but rather a true effect we can spot on many places in our ecosystem already.
Long story short: I would vote for the "fix" if the sole other option is to "remove".
Bye T.
Gesendet: Samstag, 21. April 2018 um 15:31 Uhr Von: "Stephane Ducasse" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Do we kill the catalog?
Torsten
Sometimes you should relax. Because if you remember I pushed the catalog (in fact I love it and we need a much more powerful one) and I even improved it. I made it better to automatically add MC repositories. Of course Thierry is exagerating.
Now we should fix or remove it. Simple no?
Now you can rant in your corner thinking that I'm asshole. This is ok for me.
Stef
On Sat, Apr 21, 2018 at 3:06 PM, Torsten Bergmann <astares@gmx.de> wrote:
Even there is no learning from the past - it's deja vu all over again...
Gesendet: Freitag, 20. April 2018 um 08:53 Uhr Von: "Stephane Ducasse" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Do we kill the catalog?
Hi torsten
the wise shows the moon, the idiot sees his finger.
Stef
On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares@gmx.de> 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" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Do we kill the catalog?
Hi guys
What do we do with it? What alternatives?
Stef
2018-04-24 7:31 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 24 Apr 2018, at 00:49, monty <monty2@programmer.net> wrote:
+1.
Replacing is sometimes necessary (Sven's stream work is an obvious example), but I don't see why Nautilus had to be junked rather than gradually evolved into Calypso. And I don't see why the catalog can't be gradually evolved into something better. Killing it off would be discouraging to the users who went through the trouble of adding #catalogXXX methods to their configs and publishing them to the meta repos. Why would they bother adopting whatever replaces the catalog if they think it will just get killed off too?
___ montyos.wordpress.com
Nice blog, BTW!
And I note: Publishing Configurations to Pharo Meta Repositories https://montyos.wordpress.com/2018/04/22/publishing-configurations-to-pharo-... Thierry
Hi all, I think that we are all aligned. Stef may be "too strong" in his way of talking, but he raised an issue: we should probably do an iteration on the catalog. And I think we all agree on that? So, what would be a list of tasks for it? (I copy past what Stef put before) - Use Metacello API. Metacello new repository: 'zzz' configurationOf: 'XXX' loadVersion: #'YYY' This point should is easy. I can open an issue and work on it today. - Support for Baseline (no idea what it means) This point requires that we agree on how to publish baselines. Should we continue providing configurations that point to the baselines? I've read some rants against it. I know it may be "uncomfortable", but publishing some meta-data in a repository in XXX technology is kind of the same... We can argue about visibility and smalltalkhub's stability (I've seen new users struggling to create an account and making a satisfactory login), but this can be a separate issue. - What else? Now, I also think about what to do with the meta-repo's. Should Pharo7 see MetaRepo for pharo 5 and pharo 6 and pharo 4? or should only see the one for pharo 7? What about Pharo 6? What are the meta-repo's it is looking for? -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
Guillermo Polito wrote
Should we continue providing configurations that point to the baselines? I've read some rants against it. I know it may be "uncomfortable", but publishing some meta-data in a repository in XXX technology is kind of the same...
This seems like an implementation detail. IHMO what people are really complaining about is lack of tool support to map some standard, repeatable trustability system like a Config's #stable and #development to a baseline that refers to an exact snapshot of code (i.e. commitish in git parlance IIUC). ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi Sean, Guille, 2018-04-24 15:31 GMT+02:00 Sean P. DeNigris <sean@clipperadams.com>:
Guillermo Polito wrote
Should we continue providing configurations that point to the baselines? I've read some rants against it. I know it may be "uncomfortable", but publishing some meta-data in a repository in XXX technology is kind of the same...
Baselines are simple. If using a baseline in the Catalog forces it to be more complex (like need to add a repository url in the baseline), then do not do it and only support configurations.
This seems like an implementation detail. IHMO what people are really complaining about is lack of tool support to map some standard, repeatable trustability system like a Config's #stable and #development to a baseline that refers to an exact snapshot of code (i.e. commitish in git parlance IIUC).
Sort of. A typical git-based development is one tag or branch per pharo version, hence one BaselineOf per supported Pharo version. A single configuration in the Catalog can triage on those baselines, and be used by multiple Pharo versions (4, 5, 6, 7, etc...) This would point out to having only one repository for the Catalog (for all Pharo versions); but the ability for the Catalog to filter out Configurations that are not updated on newer versions. Bonus: if you're tracking Pharo versions in your branches (if you have pharo5.0, pharo6.0, pharo7.0 branches, for example), it may be possible to write a generic url in the configurationOf, like that: repository: 'github://dalehenrich/filetree:pharo', SystemVersion current dottedMajorMinor ,'_dev/repository' Bonus+: you can also play with Unix / Windows dependent branches (because you can also query additional system attributes) Bonus++: Smalltalkhub repositories would still work... Feature: it would be nice to be able to test if the current version-dependent branch or tag exists on the target (i.e. query github), then it would be easy to write something like -> no pharo8.0 branch on repository ? Not available on Pharo8. Thierry
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Thierry Goubier wrote
If using a baseline in the Catalog forces it to be more complexâ¦
I didn't think we were discussing changing baselines themselves, just a better adapter layer than hand-edited Configs Thierry Goubier wrote
A typical git-based development is one tag or branch per pharo version, hence one BaselineOf per supported Pharo version.
Hmm, I didn't know that. I have not been using that workflow, but '*-PlatformPharo60' packages. I wonder what the tradeoffs are⦠----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Just for the record https://pharo.fogbugz.com/f/cases/21825/Improve-Catalog-loading https://github.com/pharo-project/pharo/pull/1292 Feel free to review or to propose other PRs, Guille
Thanks! ___ montyos.wordpress.com
Sent: Tuesday, April 24, 2018 at 1:31 AM From: "Sven Van Caekenberghe" <sven@stfx.eu> To: "Pharo Development List" <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] Do we kill the catalog?
On 24 Apr 2018, at 00:49, monty <monty2@programmer.net> wrote:
+1.
Replacing is sometimes necessary (Sven's stream work is an obvious example), but I don't see why Nautilus had to be junked rather than gradually evolved into Calypso. And I don't see why the catalog can't be gradually evolved into something better. Killing it off would be discouraging to the users who went through the trouble of adding #catalogXXX methods to their configs and publishing them to the meta repos. Why would they bother adopting whatever replaces the catalog if they think it will just get killed off too?
___ montyos.wordpress.com
Nice blog, BTW!
Your XML work is much appreciated.
Sent: Sunday, April 22, 2018 at 9:29 AM From: "Torsten Bergmann" <astares@gmx.de> To: pharo-dev@lists.pharo.org Cc: "Pharo Development List" <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] Do we kill the catalog?
Hi Stef,
do not worry - I'm fully relaxed. It is you - who suggested to kill the catalog - without having or proposing a suitable alternative yet. If you want to route the thread to talking about "idiots" and "assholes" you go offtopic and I guess I have nothing more to contribute to the discussion.
If it was not clear from my writing: I only expressed my wish that we should better improve it instead of killing it. That's all.
Because anytime we have a better idea we get more disruptive in what we provide ... and this leads to the unfortunate situation:
- that we replace our own stuff with newer ones again and again (which can but must not be good as things get more diverse and complicated over time) - that users have to know how things historically have been progressed to find its way through Pharo (including the terms and tools we use)
I would not see this as a rant - but rather a true effect we can spot on many places in our ecosystem already.
Long story short: I would vote for the "fix" if the sole other option is to "remove".
Bye T.
Gesendet: Samstag, 21. April 2018 um 15:31 Uhr Von: "Stephane Ducasse" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Do we kill the catalog?
Torsten
Sometimes you should relax. Because if you remember I pushed the catalog (in fact I love it and we need a much more powerful one) and I even improved it. I made it better to automatically add MC repositories. Of course Thierry is exagerating.
Now we should fix or remove it. Simple no?
Now you can rant in your corner thinking that I'm asshole. This is ok for me.
Stef
On Sat, Apr 21, 2018 at 3:06 PM, Torsten Bergmann <astares@gmx.de> wrote:
Even there is no learning from the past - it's deja vu all over again...
Gesendet: Freitag, 20. April 2018 um 08:53 Uhr Von: "Stephane Ducasse" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Do we kill the catalog?
Hi torsten
the wise shows the moon, the idiot sees his finger.
Stef
On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares@gmx.de> 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" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Do we kill the catalog?
Hi guys
What do we do with it? What alternatives?
Stef
hi,
On 24 Apr 2018, at 00:49, monty <monty2@programmer.net> wrote:
+1.
Replacing is sometimes necessary (Sven's stream work is an obvious example), but I don't see why Nautilus had to be junked rather than gradually evolved into Calypso.
thatâs clearly because you didnât see nautilus at the inside. In fact, calypso started like that⦠we wanted to refactor nautilus into something usable, but after losing two months of Denis work, we decided to go other direction, since it was just impossible to do it properly without doing it again. And the effort of doing it from scratch was less than âdestroy the house for the inside but let the façadeâ that would have been working with Nautilus. Also, in the case of Nautilus (or any system browser), there is the adding complexity of refactoring within itself. Not everything can be refactored/patched up to the infinite.
And I don't see why the catalog can't be gradually evolved into something better. Killing it off would be discouraging to the users who went through the trouble of adding #catalogXXX methods to their configs and publishing them to the meta repos. Why would they bother adopting whatever replaces the catalog if they think it will just get killed off too?
catalog was a âtemporary pieceâ that stayed for years. it was never intend to stay because it has some important limitations. said that, it can evolve from the quasi-prototype it is now (I should know, it was me who did it) to a real catalog. curiously, Iâm thinking one part of making it better would be simplify it, but thatâs another story. I wonder why people is so concerned about the use of âkilling catalogâ phrase. If you know the history of Pharo, we never âkillâ anything we do not have a replacement for it so it was never in the table a proposal of just removing it. But to be good it needs: - some better way of collect baselines than force to build a configuration - a better place to be - some kind of validation rules - etc, etc, etc. So well, in this case maybe refactor it is not an option, since many of the assumptions it has are no longer valid. cheers, Esteban
___ montyos.wordpress.com
Sent: Sunday, April 22, 2018 at 9:29 AM From: "Torsten Bergmann" <astares@gmx.de> To: pharo-dev@lists.pharo.org Cc: "Pharo Development List" <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] Do we kill the catalog?
Hi Stef,
do not worry - I'm fully relaxed. It is you - who suggested to kill the catalog - without having or proposing a suitable alternative yet. If you want to route the thread to talking about "idiots" and "assholes" you go offtopic and I guess I have nothing more to contribute to the discussion.
If it was not clear from my writing: I only expressed my wish that we should better improve it instead of killing it. That's all.
Because anytime we have a better idea we get more disruptive in what we provide ... and this leads to the unfortunate situation:
- that we replace our own stuff with newer ones again and again (which can but must not be good as things get more diverse and complicated over time) - that users have to know how things historically have been progressed to find its way through Pharo (including the terms and tools we use)
I would not see this as a rant - but rather a true effect we can spot on many places in our ecosystem already.
Long story short: I would vote for the "fix" if the sole other option is to "remove".
Bye T.
Gesendet: Samstag, 21. April 2018 um 15:31 Uhr Von: "Stephane Ducasse" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Do we kill the catalog?
Torsten
Sometimes you should relax. Because if you remember I pushed the catalog (in fact I love it and we need a much more powerful one) and I even improved it. I made it better to automatically add MC repositories. Of course Thierry is exagerating.
Now we should fix or remove it. Simple no?
Now you can rant in your corner thinking that I'm asshole. This is ok for me.
Stef
On Sat, Apr 21, 2018 at 3:06 PM, Torsten Bergmann <astares@gmx.de> wrote:
Even there is no learning from the past - it's deja vu all over again...
Gesendet: Freitag, 20. April 2018 um 08:53 Uhr Von: "Stephane Ducasse" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Do we kill the catalog?
Hi torsten
the wise shows the moon, the idiot sees his finger.
Stef
On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares@gmx.de> 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" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Do we kill the catalog?
Hi guys
What do we do with it? What alternatives?
Stef
Sent: Tuesday, April 24, 2018 at 3:42 AM From: "Esteban Lorenzano" <estebanlm@gmail.com> To: "Pharo Development List" <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] Do we kill the catalog?
hi,
On 24 Apr 2018, at 00:49, monty <monty2@programmer.net> wrote:
+1.
Replacing is sometimes necessary (Sven's stream work is an obvious example), but I don't see why Nautilus had to be junked rather than gradually evolved into Calypso.
thatâs clearly because you didnât see nautilus at the inside.
Actually, I did see the inside, to improve its SUnit integration.
In fact, calypso started like that⦠we wanted to refactor nautilus into something usable, but after losing two months of Denis work, we decided to go other direction, since it was just impossible to do it properly without doing it again. And the effort of doing it from scratch was less than âdestroy the house for the inside but let the façadeâ that would have been working with Nautilus. Also, in the case of Nautilus (or any system browser), there is the adding complexity of refactoring within itself. Not everything can be refactored/patched up to the infinite.
And I don't see why the catalog can't be gradually evolved into something better. Killing it off would be discouraging to the users who went through the trouble of adding #catalogXXX methods to their configs and publishing them to the meta repos. Why would they bother adopting whatever replaces the catalog if they think it will just get killed off too?
catalog was a âtemporary pieceâ that stayed for years. it was never intend to stay because it has some important limitations. said that, it can evolve from the quasi-prototype it is now (I should know, it was me who did it) to a real catalog.
curiously, Iâm thinking one part of making it better would be simplify it, but thatâs another story.
I wonder why people is so concerned about the use of âkilling catalogâ phrase. If you know the history of Pharo, we never âkillâ anything we do not have a replacement for it so it was never in the table a proposal of just removing it. But to be good it needs:
- some better way of collect baselines than force to build a configuration - a better place to be - some kind of validation rules - etc, etc, etc.
So well, in this case maybe refactor it is not an option, since many of the assumptions it has are no longer valid.
cheers, Esteban
___ montyos.wordpress.com
Sent: Sunday, April 22, 2018 at 9:29 AM From: "Torsten Bergmann" <astares@gmx.de> To: pharo-dev@lists.pharo.org Cc: "Pharo Development List" <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] Do we kill the catalog?
Hi Stef,
do not worry - I'm fully relaxed. It is you - who suggested to kill the catalog - without having or proposing a suitable alternative yet. If you want to route the thread to talking about "idiots" and "assholes" you go offtopic and I guess I have nothing more to contribute to the discussion.
If it was not clear from my writing: I only expressed my wish that we should better improve it instead of killing it. That's all.
Because anytime we have a better idea we get more disruptive in what we provide ... and this leads to the unfortunate situation:
- that we replace our own stuff with newer ones again and again (which can but must not be good as things get more diverse and complicated over time) - that users have to know how things historically have been progressed to find its way through Pharo (including the terms and tools we use)
I would not see this as a rant - but rather a true effect we can spot on many places in our ecosystem already.
Long story short: I would vote for the "fix" if the sole other option is to "remove".
Bye T.
Gesendet: Samstag, 21. April 2018 um 15:31 Uhr Von: "Stephane Ducasse" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Do we kill the catalog?
Torsten
Sometimes you should relax. Because if you remember I pushed the catalog (in fact I love it and we need a much more powerful one) and I even improved it. I made it better to automatically add MC repositories. Of course Thierry is exagerating.
Now we should fix or remove it. Simple no?
Now you can rant in your corner thinking that I'm asshole. This is ok for me.
Stef
On Sat, Apr 21, 2018 at 3:06 PM, Torsten Bergmann <astares@gmx.de> wrote:
Even there is no learning from the past - it's deja vu all over again...
Gesendet: Freitag, 20. April 2018 um 08:53 Uhr Von: "Stephane Ducasse" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Do we kill the catalog?
Hi torsten
the wise shows the moon, the idiot sees his finger.
Stef
On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares@gmx.de> 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" <stepharo.self@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Do we kill the catalog?
Hi guys
What do we do with it? What alternatives?
Stef
___ montyos.wordpress.com
participants (16)
-
Ben Coman -
Cyril Ferlicot -
Cyril Ferlicot D.
-
Esteban A. Maringolo -
Esteban Lorenzano -
Gabriel Cotelli -
Guillermo Polito -
Hernán Morales Durand -
monty -
Peter Uhnák -
Sean P. DeNigris -
Stephan Eggermont -
Stephane Ducasse -
Sven Van Caekenberghe -
Thierry Goubier -
Torsten Bergmann