> On 20 Apr 2018, at 12:20, Thierry Goubier <thierry.goub...@gmail.com> wrote:
>
> Le 20/04/2018 à 11:44, Esteban Lorenzano a écrit :
>>> On 20 Apr 2018, at 11:01, Thierry Goubier <thierry.goub...@gmail.com
>>> <mailto:thierry.goub...@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 <esteba...@gmail.com
>>>> <mailto:esteba...@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.s...@gmail.com
>>>>>> <mailto:stepharo.s...@gmail.com>> wrote:
>>>>>>
>>>>>> Hi guys
>>>>>>
>>>>>> What do we do with it?
>>>>>> What alternatives?
>>>>>>
>>>>>> Stef
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
