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