About preloaded packages

Hi guys

I would really like that pharo-dev does not contain too many libraries pre loaded (for example XMLSupport).
I would favor push metacello so that in one click people can load what they want.

Stef

On 07 Jan 2011, at 09:05, Stéphane Ducasse wrote:

> I would really like that pharo-dev does not contain too many libraries pre loaded (for example XMLSupport).
> I would favor push metacello so that in one click people can load what they want.

+1

2) We like it or not, the packages that are included in the dev images are the most known, supported, maintained and tested.
3) XMLSupport has been asked in the mailing list several times

I asked which packages to include in the dev image and I never received a negative answer, check:
- http://forum.world.st/Pharo-1-2-default-packages-tp3092206p3092206.html
- http://forum.world.st/Changes-in-external-packages-for-Pharo-1-2-tp2551023p2551023.html

I would agree that XMLSupport is not installed by defaul only when we have out Metacello structure working: repository for an specific pharo version, stable versions (symbolic versions), self contained (copy all mzc), and finally the Loader to load them. Once we have that, and once that searching and installing Metacello projects is really easy, I would start removing some packages from the dev image.

Cheers

mariano

Hi Mariano,

I'm not (really) concerned with image size.

As a user of Pharo, I would expect that a Pharo dev image includes plenty of development tools and an easy way of loading external libraries (such as XML, Seaside, Glorp,....).
With the advent of metacello, we now have an easy loading mechanism for external libraries such that, to me, it's strange to see those libraries being deployed in a dev image of Pharo.

Even a development image should be a base to start from. But I would like to see a lot of development tools pre-loaded. Pharo is already doing a good job at that, btw, unlike Visualworks where the syntax highlighter and many other useful development packages are add-ons. Explaining that syntax highlighting is an external library to load is something new students always were amazed about when I exposed them to Smalltalk...

> 1) If you want to do business, XML is REALLY important. You like it or not (I promise I hate XML). APIs, legacy systems, other systems, etc...

Then again, database functionality is probably even more crucial than XML for any business app.
My point is: if you need an XML library: you can load it.

oh, and, not all business requires XML (lucky me ;-)

> 2) We like it or not, the packages that are included in the dev images are the most known, supported, maintained and tested.

So... Glorp and Seaside too?
I'm overstating.... but there are so many good and useful packages out there that is seems strange to include some and others not.

> 3) XMLSupport has been asked in the mailing list several times

Well, it's not because people ask that it's a good thing. This also applies to my own mail, btw :-)) (it's just my opinion)

>  Once we have that, and once that searching and installing Metacello projects is really easy, I would start removing some packages from the dev image.

I see your point, but XML is really easily installable already.

But hey, I'm just expressing my opinion here and sorry that I did not react to any previous email (it's a bit too much for me).

cheers,
Johan

On 07 Jan 2011, at 11:17, Johan Brichau wrote:

> I'm not (really) concerned with image size.
>
> As a user of Pharo, I would expect that a Pharo dev image includes plenty of development tools and an easy way of loading external libraries (such as XML, Seaside, Glorp,....).
> With the advent of metacello, we now have an easy loading mechanism for external libraries such that, to me, it's strange to see those libraries being deployed in a dev image of Pharo.
>
> Even a development image should be a base to start from. But I would like to see a lot of development tools pre-loaded. Pharo is already doing a good job at that, btw, unlike Visualworks where the syntax highlighter and many other useful development packages are add-ons. Explaining that syntax highlighting is an external library to load is something new students always were amazed about when I exposed them to Smalltalk...

Advanced users, such as most people on this list, will construct their own images based on either Core or Dev, I guess. So the main target is people starting out or other checking out pharo. Loading big packages such as Seaside or Glorp takes some time and is not always easy. So there is definitively value in having things preloaded.

A lot of work goes into building Dev and it constitutes a really useful baseline of tested code which is very important to how other perceive Pharo.

Maybe there could be more than one Dev version ?

Sven

To answer this question you actually need to know who pharo-dev is targeted at and what they expect from it.  I reckon pharo-dev should come with the core bells-and-whistles the Pharo project would like to showcase, so yes do include the Seaside, XML etc in pharo-dev so newbies don't have to worry about finding out what to load from where to do things they expect to be included.  Those who want a clean images and only load what they need can always start from the pharo (core) image.

+1

"but" I really would include Metacello Browser (or a modified version adapted for us) in the image...

Cheers,
Esteban

El 07/01/2011, a las 5:05a.m., Stéphane Ducasse escribió:

> Hi guys
>
> I would really like that pharo-dev does not contain too many libraries pre loaded (for example XMLSupport).
> I would favor push metacello so that in one click people can load what they want.
>
> Stef

I really liked the web image of the early days and would like to see Hudson build something similar for us.  First, the servers required for loading various packages are not always alive.  Having Hudson grabbing things would: (1) monitor the servers' health for us (if builds succeed, they are ok); (2) prevent all of our have to individually load things, reducing the load on the servers and probably helping to ensure correct selection of versions in the images that are built.

With Hudson making lean, full dev and Seaside images (maybe others), each of us could choose between pre-built or home-grown images.

Bill


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Johan Brichau [[hidden email]]
Sent: Friday, January 07, 2011 5:17 AM
To: [hidden email]
Subject: Re: [Pharo-project] About preloaded packages

Hi Mariano,

I'm not (really) concerned with image size.

As a user of Pharo, I would expect that a Pharo dev image includes plenty of development tools and an easy way of loading external libraries (such as XML, Seaside, Glorp,....).
With the advent of metacello, we now have an easy loading mechanism for external libraries such that, to me, it's strange to see those libraries being deployed in a dev image of Pharo.

Even a development image should be a base to start from. But I would like to see a lot of development tools pre-loaded. Pharo is already doing a good job at that, btw, unlike Visualworks where the syntax highlighter and many other useful development packages are add-ons. Explaining that syntax highlighting is an external library to load is something new students always were amazed about when I exposed them to Smalltalk...

> 1) If you want to do business, XML is REALLY important. You like it or not (I promise I hate XML). APIs, legacy systems, other systems, etc...

Then again, database functionality is probably even more crucial than XML for any business app.
My point is: if you need an XML library: you can load it.

oh, and, not all business requires XML (lucky me ;-)

> 2) We like it or not, the packages that are included in the dev images are the most known, supported, maintained and tested.

So... Glorp and Seaside too?
I'm overstating.... but there are so many good and useful packages out there that is seems strange to include some and others not.

> 3) XMLSupport has been asked in the mailing list several times

Well, it's not because people ask that it's a good thing. This also applies to my own mail, btw :-)) (it's just my opinion)

>  Once we have that, and once that searching and installing Metacello projects is really easy, I would start removing some packages from the dev image.

I see your point, but XML is really easily installable already.

But hey, I'm just expressing my opinion here and sorry that I did not react to any previous email (it's a bit too much for me).

cheers,
Johan

+1 (and Hudson is a great way to build the various targets).



________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Sven Van Caekenberghe [[hidden email]]
Sent: Friday, January 07, 2011 5:38 AM
To: [hidden email]
Subject: Re: [Pharo-project] About preloaded packages

A lot of work goes into building Dev and it constitutes a really useful baseline of tested code which is very important to how other perceive Pharo.

Maybe there could be more than one Dev version ?

Sven

I concur with Mariano and wonder why Stéphane wants a smaller dev image?

Right now there are two images, the core and the dev. As the core is
promoted for deploying, the size of the dev isn't an issue. At least in
terms of deploying.

Now the dev image is currently targeted to new users, so I think that it
should have everything that is know to work in Pharo loaded,  so that
the users doesn't have to cope with the installation issue of new
packages.
This also means that tutorials and documentation can be straightforward.
Just showing what they want to teach, and not explaining what to do to
install some random package. So this will help document and promote
Pharo.

Now maybe the name dev is misleading. It says development although the
image is for everyone that is not deploying some application. On the
other side, there isn't officially a dev image, only PharoCore and
Pharo. So maybe we need to create a official PharoDev image targeted to
the developers but this is also very subjective as what packages made a
development environment, it is upon the developer. So maybe this make no
sense at all.

So the options are:

1. Refer to Pharo dev as Pharo, the official name and officially make it
targeted to new users and so include everything under the sun (like the
fun  images of Edgar, that can show off the capabilities of Pharo)
2. Create a PharoDev, with a list of common dev packages, also
officially supported

TL;DR; Pharo is for new users and should include everything preloaded.
PharoCore is for deploying and the developer install just what he wants.
Maybe a PharoDev is  needed targeted directly to developers.

Cheers
--
Miguel Cobá
http://twitter.com/MiguelCobaMtz
http://miguel.leugim.com.mx

On Jan 7, 2011, at 10:15 , Johan Brichau wrote:

>
> On 07 Jan 2011, at 09:05, Stéphane Ducasse wrote:
>
>> I would really like that pharo-dev does not contain too many libraries pre loaded (for example XMLSupport).
>> I would favor push metacello so that in one click people can load what they want.
>
> +1

+1

I would also be rather conservative with regard to adding packages that are not developer tools.

If we add XML we should probably also add XYZ. Wouldn't it make sense to add Seaside too? The problem here is not primarily the larger image file size, but the image becomes bloated in general (e.g., search results) and there's a risk of conflicts (e.g., we are using the pharo-dev image, but with our own Seaisde 2.9 version; if the image comes with a preinstalled Seaside 3, we couldn't use it anymore).

It appears to me that preloading packages like XML is just points out that a good package manager is missing.

Cheers,
Adrian  

>
>
> -1
>
> Sorry, But I don't agree. Who cares the size of a development image? You are not going to deploy it.

But we have to do the "oh let us fix this bug"

> The less effort for new comers to get what they want, the best.

They can click and load.

On Jan 7, 2011, at 5:10 PM, Miguel Cobá wrote:

> I concur with Mariano and wonder why Stéphane wants a smaller dev image?

Because we have to fix bug of packages that we do not know, control, want to fix...
Because been agile to load and having a good infrastructure for validating packages is way more
important than preloading XML. If we spend our time on the infrastructure (metacello publication,
configuration certification, hudson reporting) then the complete ecosystem will get better
and you should be able to automate several builds and pharo-dev whatever.

I'm concerned that our resources are limited and they are a lot of ugly ugly things in the system
Now not everybody should work on them but then the insfrastructure is more important.

> I would also be rather conservative with regard to adding packages that are not developer tools.
>
> If we add XML we should probably also add XYZ. Wouldn't it make sense to add Seaside too? The problem here is not primarily the larger image file size, but the image becomes bloated in general (e.g., search results) and there's a risk of conflicts (e.g., we are using the pharo-dev image, but with our own Seaisde 2.9 version; if the image comes with a preinstalled Seaside 3, we couldn't use it anymore).
>
> It appears to me that preloading packages like XML is just points out that a good package manager is missing.

Yes
for example moose people get problem because when they load the latest version of XMLsupport on pharodev1.2 the system barks.
While pharo-dev (with tools not frameworks) is an ok image to build systems like moose.
Stef

The tool is already there as torsten mentioned. Now what is missing are configurationOf published in the right squeaksource folders.


> For Pharo 1.2 I'd rather leave XML in because today I expect that every programming environment used in enterprise supports XML out of the box.

why ruby, python, .... java does it without an import statement?

> It would also like a PharoBloat image built by Hudson with all ConfigurationOfXXX which are supposed to work on all operating systems.

Not loaded :)
Just published in the right squeaksource repository and validated (run, tests run and results shown....) via an hudson server.

My concern about Metacello has always been that while it is terribly easy to use, it is very potentially difficult to know what to ask it to do.  I *think* I have seen signs of improvement and increasing uniformity since I began playing with 1.2.  The ConfigurationBrowser probably brought the confusion to light.  

The ConfiguationBrowser's load latest version command will either force a direct way to do that on all configurations (or at least stand as a reference on how to do it by reflecting on the configuration), but then there is another, bigger, and (I suspect) unsolvable problem: knowing which version to load of any given package.  That is a good problem to have (lots of stuff being developed), but we have to acknowledge it.

Laurent's Pharo-bloat idea is interesting.  While it is not a build target that I would probably want to use, it makes a lot of sense for the Pharo brand to load the latest stable version of just about everything and report on test results.  There will still be quirks: when did/does Seaside 3.0 replace 2.8?  Of course, one can always start with the core and build anything, but the Pharo Hudson server probably should build things including:

(1) recommended Pharo/Pharo-dev - whatever you want to call it, but it's a good starting point for general use;
(2) Pharo web, above plus Seaside, Magritte;
...
(n) Pharo-package-testing - everything, primarily to see if it builds and to get test results


Bill



________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]]
Sent: Saturday, January 08, 2011 9:00 AM
To: [hidden email]
Subject: Re: [Pharo-project] About preloaded packages

> I would also be rather conservative with regard to adding packages that are not developer tools.
>
> If we add XML we should probably also add XYZ. Wouldn't it make sense to add Seaside too? The problem here is not primarily the larger image file size, but the image becomes bloated in general (e.g., search results) and there's a risk of conflicts (e.g., we are using the pharo-dev image, but with our own Seaisde 2.9 version; if the image comes with a preinstalled Seaside 3, we couldn't use it anymore).
>
> It appears to me that preloading packages like XML is just points out that a good package manager is missing.

Yes
for example moose people get problem because when they load the latest version of XMLsupport on pharodev1.2 the system barks.
While pharo-dev (with tools not frameworks) is an ok image to build systems like moose.
Stef

Stef,

I'm not sure I follow.  I think we agree that loading all configurations and running tests is good.  I understand why the web image went away when it took somebody's time time build it, but the Hudson server can do that work now.  It seems reasonable to leave a range of targets that might be of value to people.  There could be a few likely useful targets (minimal, dev, web) and then one with absolutely everything that is mostly for testing.  But if somebody wants to use that, why not leave it on the server so they can get it?

Bill



________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]]
Sent: Saturday, January 08, 2011 10:30 AM
To: [hidden email]
Subject: Re: [Pharo-project] About preloaded packages

> It would also like a PharoBloat image built by Hudson with all ConfigurationOfXXX which are supposed to work on all operating systems.

Not loaded :)
Just published in the right squeaksource repository and validated (run, tests run and results shown....) via an hudson server.

On Jan 8, 2011, at 4:42 PM, Schwab,Wilhelm K wrote:

> Stef,
>
> I'm not sure I follow.  I think we agree that loading all configurations and running tests is good.

I meant that the configurations do not have to be loaded in the image.

>  I understand why the web image went away when it took somebody's time time build it, but the Hudson server can do that work now.  It seems reasonable to leave a range of targets that might be of value to people.  

yes now somebody should maintain the configuration and fix conflict.

> There could be a few likely useful targets (minimal, dev, web) and then one with absolutely everything that is mostly for testing.  But if somebody wants to use that, why not leave it on the server so they can get it?

because who maintains if there is a bug due to a conflict.
Building the seaside image took lukas time and effort. I'm learned that things do not magically work.
So if somebody stands up and say ok I'm responsible for the imageXZK why not and we can set up hudson to build it.
Now we (the core minimal team) should spend time on getting the infrastructure right on tracks because this is an enabler of the future.

+1

Doru


On 8 Jan 2011, at 17:02, Stéphane Ducasse wrote:

--
www.tudorgirba.com

"Obvious things are difficult to teach."