Andreas Raab wrote:
Let's be a bit careful before jumping heads-on into the Metacello frenzy.
Somehow I knew before that you will respond like this ... ;)
I don't mind if people choose to use Metacello to load VMMaker but it shouldn't be the only option.
Hey - Metacello is "just" a package management tool for Monticello using descriptions of the dependencies and the versions that fit together. Anything I did was to create such a configuration.
Nobody forces you or other developers to use Metacello - having such an (additional) config does not change the way you are working right now. Use Monticello, SqueakSource, ... as you did before. You can continue to use build scripts, installers, SqueakMap, Universe, whatever ... to load VMMaker.
But currently I dont see none of these "loaders" is well maintained (or only with private scripts), anything I've found was a decription from David (see last mail) on the web. And how often does one ask which packages in which version fit together to get VMMaker or other Squeak projects to work. Try to rebuild the SqueakSource server and you know what I'm talking about!
Providing and maintaining a metacello spec is simple and works. And the interesting thing is that someone (Dale) is actively maintaining this tool on several Smalltalks - even for Squeak.
And as Fernando responded on the pharo list: "And the ConfigurationOfXXX is allowing a new form of communication , unthinkable just a couple of months ago...."
Metacello easily allows to have reproducable builds for projects, applications, images ... (see http://astares.blogspot.com/2010/01/pharo-10-release-candidate-2-and-image.h...)
Someone requires VMMaker in a specific version - just point him to "ConfigurationOfVMMaker" and you are done.
Myself for example, I use customarily a variety of images, none of which support or are supported by Metacello.
Two things - this has nothing to do with Metacello. Your images dont have to have Metacello. So it is just an additional configuration, so why will you bother - it will not affect the way you worked before
- it is not the problem of the Squeak community if you use non-Squeak images to build VM's. As community we all have to assure that VMMaker and its loading (with or without Metacello) is well known and works on standard images and the loading and VM building is reproducable by ANYONE! Does the term "Truck Factor" ring a bell?
At least your images seem to be able to use Monticello - so why lament. You can continue to work as before and if David could invest a minute to save others from annoying questions about VMMaker loading everything is in good shape and even free's some time in the long term.
It would not be good if we require Metacello to load VMMaker.
Is the Linux project in trouble when one create's and publishes a CD with linux packages that fit together? No! Same applies here. You should really have a look first before commenting on Metacello...
Bye T.
Torsten Bergmann wrote:
Andreas Raab wrote:
Let's be a bit careful before jumping heads-on into the Metacello frenzy.
Somehow I knew before that you will respond like this ... ;)
Right. And that's the problem with prejudices. If you expect a response of a certain form you'll find a way to interpret what's being said to match your expectations even though the intention may have been completely different.
What I was saying to David, not to you, is that we need to make sure that we don't introduce any undue dependencies on Metacello. Given the dependencies of Metacello itself I think there is an actual risk of that happening and I simply wanted to remind David that it's important for us to make sure VMMaker doesn't require Metacello.
BTW, it is unfair to spam your message to both Squeak-dev and the Pharo list just to paint me as a nay-sayer in the community.
Cheers, - Andreas
I don't mind if people choose to use Metacello to load VMMaker but it shouldn't be the only option.
Hey - Metacello is "just" a package management tool for Monticello using descriptions of the dependencies and the versions that fit together. Anything I did was to create such a configuration.
Nobody forces you or other developers to use Metacello - having such an (additional) config does not change the way you are working right now. Use Monticello, SqueakSource, ... as you did before. You can continue to use build scripts, installers, SqueakMap, Universe, whatever ... to load VMMaker.
But currently I dont see none of these "loaders" is well maintained (or only with private scripts), anything I've found was a decription from David (see last mail) on the web. And how often does one ask which packages in which version fit together to get VMMaker or other Squeak projects to work. Try to rebuild the SqueakSource server and you know what I'm talking about!
Providing and maintaining a metacello spec is simple and works. And the interesting thing is that someone (Dale) is actively maintaining this tool on several Smalltalks - even for Squeak.
And as Fernando responded on the pharo list: "And the ConfigurationOfXXX is allowing a new form of communication , unthinkable just a couple of months ago...."
Metacello easily allows to have reproducable builds for projects, applications, images ... (see http://astares.blogspot.com/2010/01/pharo-10-release-candidate-2-and-image.h...)
Someone requires VMMaker in a specific version - just point him to "ConfigurationOfVMMaker" and you are done.
Myself for example, I use customarily a variety of images, none of which support or are supported by Metacello.
Two things
this has nothing to do with Metacello. Your images dont have to have Metacello. So it is just an additional configuration, so why will you bother - it will not affect the way you worked before
it is not the problem of the Squeak community if you use non-Squeak images to build VM's. As community we all have to assure that VMMaker and its loading (with or without Metacello) is well known and works on standard images and the loading and VM building is reproducable by ANYONE! Does the term "Truck Factor" ring a bell?
At least your images seem to be able to use Monticello - so why lament. You can continue to work as before and if David could invest a minute to save others from annoying questions about VMMaker loading everything is in good shape and even free's some time in the long term.
It would not be good if we require Metacello to load VMMaker.
Is the Linux project in trouble when one create's and publishes a CD with linux packages that fit together? No! Same applies here. You should really have a look first before commenting on Metacello...
Bye T.
On 06.02.2010 00:18, Andreas Raab wrote:
What I was saying to David, not to you, is that we need to make sure that we don't introduce any undue dependencies on Metacello. Given the dependencies of Metacello itself I think there is an actual risk of that happening and I simply wanted to remind David that it's important for us to make sure VMMaker doesn't require Metacello.
Right. Try loading ConfigurationOfVMMaker though (no dependencies!) and you'll see what it really is. A declarative way to define the packages (and their versions) which need to be loaded to build a VMMaker image. You can do it manually without loading the tools used for automatic loading, or just unload the tools (gofer, metacello, configurationofxxx) after the functionality is actually loaded. I see it as improbable to make VMMaker depend on Metacello to work, as it currently is make it depend on .mcm's to work. If there's an obvious point I'm missing, please enlighten me, as I'm sure David is not the only one interested in what such undue dependencies on Metacello would actually entail.
Cheers, Henry
Henrik Sperre Johansen wrote:
On 06.02.2010 00:18, Andreas Raab wrote:
What I was saying to David, not to you, is that we need to make sure that we don't introduce any undue dependencies on Metacello. Given the dependencies of Metacello itself I think there is an actual risk of that happening and I simply wanted to remind David that it's important for us to make sure VMMaker doesn't require Metacello.
Right. Try loading ConfigurationOfVMMaker though (no dependencies!) and you'll see what it really is. A declarative way to define the packages (and their versions) which need to be loaded to build a VMMaker image. You can do it manually without loading the tools used for automatic loading, or just unload the tools (gofer, metacello, configurationofxxx) after the functionality is actually loaded. I see it as improbable to make VMMaker depend on Metacello to work, as it currently is make it depend on .mcm's to work. If there's an obvious point I'm missing, please enlighten me, as I'm sure David is not the only one interested in what such undue dependencies on Metacello would actually entail.
If there are none, that's great. However, the last time I loaded some Metacello stuff (which is a couple of weeks ago) it pulled in all sorts of things including OmniBrowser and left some modification in other packages. If that has been fixed since, all the better.
Cheers, - Andreas
On 06.02.2010 00:40, Andreas Raab wrote:
Henrik Sperre Johansen wrote:
On 06.02.2010 00:18, Andreas Raab wrote:
What I was saying to David, not to you, is that we need to make sure that we don't introduce any undue dependencies on Metacello. Given the dependencies of Metacello itself I think there is an actual risk of that happening and I simply wanted to remind David that it's important for us to make sure VMMaker doesn't require Metacello.
Right. Try loading ConfigurationOfVMMaker though (no dependencies!) and you'll see what it really is. A declarative way to define the packages (and their versions) which need to be loaded to build a VMMaker image. You can do it manually without loading the tools used for automatic loading, or just unload the tools (gofer, metacello, configurationofxxx) after the functionality is actually loaded. I see it as improbable to make VMMaker depend on Metacello to work, as it currently is make it depend on .mcm's to work. If there's an obvious point I'm missing, please enlighten me, as I'm sure David is not the only one interested in what such undue dependencies on Metacello would actually entail.
If there are none, that's great. However, the last time I loaded some Metacello stuff (which is a couple of weeks ago) it pulled in all sorts of things including OmniBrowser and left some modification in other packages. If that has been fixed since, all the better.
Cheers,
- Andreas
If OmniBrowser is defined as a prerequisite for what you are trying to load with Metacello, then yes, it will pull that in. If a squeak-specific If you try to load Metacello with ConfigurationOfMetacello, it will load Gofer, which is the Installer-equivalent package it uses to load packages. If any of the prereqs include extension methods/overrides, then yes, you will have dirty packages afterwards, for the same reason you would get that when loading the package from Monticello manually.
I think I see your point now though, no external packages only part of a ConfigurationOfMetacello should be required for VMMaker to work/alter the default behaviour of VMMaker in a way which is required for it to work. To this I agree fully, please note this is already the situation with the -Pools packages though, if you want to build all VMMaker-included plugins properly.
Cheers, Henry
PS. If you have loaded the ConfigurationOfVMMaker, you might want to look at the grouping feature. While the default is to load all plugins, it's easy (well, with the Metacello tools installed ;) ) to load just a core install, or a selection of the plugins you like as well.
Henrik Sperre Johansen wrote:
If OmniBrowser is defined as a prerequisite for what you are trying to load with Metacello, then yes, it will pull that in.
One of the things that's really hard with Metacello is understanding what depends on Metacello and what depends on the application package. I'm pretty sure that when I tried it previously, it was Metacello itself that loaded OB, but since it's a while ago I could be misremembering.
However, it appears that when loading the ConfigurationOfVMMaker it doesn't pull in OB (great!) and the only dirty package is the Freetype vs. Freetype-Plugin dependency. This is *much* better than what I've previously seen.
I think I see your point now though, no external packages only part of a ConfigurationOfMetacello should be required for VMMaker to work/alter the default behaviour of VMMaker in a way which is required for it to work. To this I agree fully, please note this is already the situation with the -Pools packages though, if you want to build all VMMaker-included plugins properly.
Yes, and I really dislike that situation, too.
Cheers, - Andreas
Torsten Bergmann wrote:
Andreas Raab wrote:
Let's be a bit careful before jumping heads-on into the Metacello frenzy.
Somehow I knew before that you will respond like this ... ;)
Right. And that's the problem with prejudices. If you expect a response of a certain form you'll find a way to interpret what's being said to match your expectations even though the intention may have been completely different.
What I was saying to David, not to you, is that we need to make sure that we don't introduce any undue dependencies on Metacello. Given the dependencies of Metacello itself I think there is an actual risk of that happening and I simply wanted to remind David that it's important for us to make sure VMMaker doesn't require Metacello.
BTW, it is unfair to spam your message to both Squeak-dev and the Pharo list just to paint me as a nay-sayer in the community.
Cheers,
- Andreas
I don't mind if people choose to use Metacello to load VMMaker but it shouldn't be the only option.
Hey - Metacello is "just" a package management tool for Monticello using descriptions of the dependencies and the
It's is not "just a package manager" it is huge and totally over engineered for the purpose you have in mind. You are talking 40 classes! VMMaker is at a far lower level than Seaside or other things Metacello is being used for.
Installer has a mechanism that is much better suited to this purpose, a simple readable DSL for loading things. You can put scripts into InstallerScripts to be loaded using
Installer install: 'VMMaker'.
this is very simple, and you can publish variants for all different platforms.
versions that fit together. Anything I did was to create such a configuration. Nobody forces you or other developers to use Metacello - having such an (additional) config does not change the way you are working right now. Use Monticello, SqueakSource, ... as you did before. You can continue to use build scripts, installers, SqueakMap, Universe, whatever ... to load VMMaker. But currently I dont see none of these "loaders" is well maintained (or only with private scripts), anything I've found was a
What do you need to be maintained. Installer was written in 2006 and has been working fine ever since, has been majorly refactored, and the api has stayed consistent, through all of that time. There is very little to maintain on installer, that is often the key to effective maintenance.
Sake/Packages just adds dependencies, it too is small and relatively simple. S/P has been relatively stable for a long period. In S/P If you need a package to load, you maintain it. It is for the users to maintain.
I am certainly not convinced as to why you need Metacello, to achieve what Installer used to do in one class.
decription from David (see last mail) on the web. And how often does one ask which packages in which version fit together to get VMMaker or other Squeak projects to work. Try to rebuild the SqueakSource server and you know what I'm talking about! Providing and maintaining a metacello spec is simple and works. And the
I don't agree. Nothing about Metacello strikes me as simple.
I could comment on the rest of your post, I basically disagree with pretty much everything you say.
Can Metacello publish and use definitions on a web page or wiki, can it load from squeakmap, or universes, can it access published bug fixes, can you override with your own local definitions, can it bootstrap from the source.st code inside a monticello package.
If you look at the range of functionality in the existing tools we have had for along time, Metacello really isn't offering anything of interest, and is certainly overkill for VMMaker.
cheers
Keith
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Henrik Sperre Johansen -
keith -
Torsten Bergmann