Re: [Pharo-dev] It would be too expensive to add a description for packages in Configuration Browser?

Sun, 08 Dec 2013 14:05:50 -0800

Hi Hernan,
 
the problem is not the button - but the missing standard and standardized descriptions
on the configs...
 
For instance I also write markup docu on my configs (see ConfigurationOfINIFile) - it
is loadable as a usual config but adds two class side methods: #documentation
and #tutorialOn: using the <onlineTutorial> pragma.
 
The documentation is stored as class comment in markdown format on the 
ConfigurationOfINIFile class. I use the same description then for the STHub project page.
 
If one loads additionally the "PharoOnlineHelp" package afterwards it will also appear
magically in my Pharo online help as a tutorial. This was my proposal - but so far it looks
like nobody is really interested. 

Maybe because often this ends in "which syntax" discussions and due to the lack of
good in image default text display facilities for markup, pier-syntax, ...
 
In general it can be done easily, but we have to agree on some kind of  "common standard"
for configurations and documentation on 
 - how to describe a package (also the format, either markdown or pier syntax with http://smalltalkhub.com/#!/~Pier/Pillar)
 - how to name the methods or pragmas that are used
 
Stef also did something (with Catalog), the ConfigurationOfINIFile for instance has two supporting
methods: #catalogDescription and #repositoryUrlString.  
Still Catalog uses Pier and is not really visible - and STHub does support markdown by default. 
 
As of today I would like to see Pharo moving into the following direction:
 - using the configs for describing the help/documentation/package descriptions
 - also tagging with package categories (for instance there are packages/projects for "database access", others for "parsers", or "games")
 - maybe use pier syntax for descriptions (it can be parsed by Pillar and other formats like HTML, markdown, Latex, ... be generated)
    but with a better design and visibility like "http://packages.pharo.org"
   together with a loadable list for the config browser
 - when one uploads such a ConfigurationOfMyKillerApp to STHub it should automagically update the
    STHub description (which is currently only possible via the web interface)
 - additional rankings (number of downloads like on STHub,  successful CI builds, member rankings, ...)
 - automated verfication
 - ... <snip>lot of other ideas</snip>
 
Bye
T.
 
Gesendet: Sonntag, 08. Dezember 2013 um 22:12 Uhr
Von: "Hernán Morales Durand" <[email protected]>
An: "Pharo Development List" <[email protected]>
Betreff: Re: [Pharo-dev] It would be too expensive to add a description for packages in Configuration Browser?
Hi Torsten,
 
2013/12/8 Torsten Bergmann <[email protected]>
The reason is simple: when I wrote the config browser
there was no such additional description on the configs itself
and one would have to load the config into the image first.

Think of 2000 config's (note each is a package) loading in the future when
the config browser opens. This will take ages. I think this is not good
since the app should be responsive.

Maybe a "show details" button helps when the package is selected.
 

 
I agree (see attached screenshot). I have added the button but the thing is: Package can be fetched from the repository, but there is no package description. There are only textual descriptions of commits.
 
So anyone see any workaround here?

 

I would rather see:
 1. Either a simple hosted seaside app "Pharo Store" that one can use to
    register a config for a specific pharo version (similar like squeakmap)
    maybe directly from the STHub interface with description, ...

    This app can be queried by the config browser (JSON/XML/Fuel/...)
    to display infos on the package, maybe also a rating about downloads, ...

 2. Or a general mechanism that loads the configs, runs tests and if
    OK provides them for the config browser as "yes these config really work"
 
 
Absolutely. Configurations should be certified.

 
Hernán
 

Reply via email to