On 22 February 2010 19:20, Andreas Raab <andreas.raab at gmx.de> wrote:
> Igor Stasenko wrote:
>>
>> I agree with Keith here.
>
> And I disagree :-)
>
>> The 'declarativeness' of package configs makes no sense to me. What it
>> can be used for?
>
> Ensure that it can be understood many years from now. Simple as that. Look
> at your ConfigurationsOfXXX. Assume that twenty years from now someone is
> trying to load one of them. What's going to happen? It will try to find
> stuff on Lukas' site (Gofer) it will try to find stuff on Gemstone's site
> (Metacello) and those sites may long be gone.
>
> Now you're back to reading what's in it. Look at ConfigurationOfXXX. I know
> my Squeak pretty well, but that stuff is gobbly gook to me. I can't make
> sense of half of it. Installer is better in this regard but these things
> always end up with more convenience stuff which causes more complexity and
> will make it harder if not impossible to read 20 years from now.
>
> Compare this with a simple alternative (I'm not using XML because of the
> knee-jerk reaction to XML in this community):
>
> [Disclaimer: Please folks, don't come back and give this "oh but it doesn't
> do x,y,z" response that I can see coming at me. This is NOT an actual
> package spec, this is an example for what a simple package spec *might look
> like*]
>
> Package: HelpSystem-Core
> Version: 1.0
> Repository: http://www.squeaksource.com/HelpSystem
> Installs: HelpSystem-Core-tbn.1.mcz
> Installs: HelpSystem-Tests-tbn.1.mcz
>
> Package: HelpSystem
> Version: 1.0
> IntendedPlatform: Squeak
> IntendedVersion: 3.10
> Requires: HelpSystem-Core
> Repository: http://www.squeaksource.com/HelpSystem
> Installs: Squeak-Project-Help.1.mcz
>
> Package: HelpSystem
> Version: 1.0
> IntendedPlatform: Pharo
> IntendedVersion: 1.0
> Requires: HelpSystem-Core
> Repository: http://www.squeaksource.com/HelpSystem
> Installs: Pharo-Project-Help.1.mcz
>
> Package: HelpSystem
> Version: 1.1
> IntendedPlatform: Squeak
> IntendedVersion: 4.0
> Requires: HelpSystem-Core
> Repository: http://www.squeaksource.com/HelpSystem
> Installs: Squeak-Project-Help-tbn.4.mcz
>
> You can *read this and understand what it means*. You can fully document it
> in about fifteen minutes. You can write a parser that reads such definitions
> in five minutes (two if you'd be using XML because you'd have the parser
> already). And you *won't* be trying to add "convenience functions" because
> you're not programming *in it* but rather write interfaces that deal with
> it.
>

The more formal, more declarative, more obscure the description is,
the less useful it becomes.
So, the question is, do we need such obscure form (as in your
examples), or we need something more sophisticated,
which can handle different nuances more directly (using scripting).
Smalltalk is open system. And anything could happen over 20 years with it.
A unix-based systems is frozen and bound to C to its death. What is
their advantage, is at same time, their main disadvantage - inability
to evolve.
So, if we're moving towards replacing Linux shell (and then freeze for
the rest of existance), making such configs is the way to go. ;)

> The thing that's by far the most screwed up about Metacello is that in
> practice the ConfigurationsOfXXX are used as input, instead as generator of
> the proper specs. Nobody will be able to load one of these
> ConfigurationsOfXXX twenty years from now. The sites will have changed, the
> code will have changed, the interfaces will have changed. Assuming that this
> code will load twenty years from now is *incredibly* naive. Assuming that a
> simple format like the above can survive essentially unchanged is not.
>
>> The only thing, where it can be useful is to show us, what you may
>> need when browsing the package(s) on server. Or compare two different
>> configs? I barely see much usefullness in it. The main purpose of
>> package management tools is to be able to load/unload a code. The rest
>> is optional.
>
> Obviously loading and unloading are crucial parts, but so is having the
> ability for the package management system to describe what you've loaded. In
> business, not being able to go back and say "gee, they're running version
> X.Y.Z over there, was the bug #3912 fixed in this version?" will kill you.
>

Remember the issue with UUID library, which causing Squeak VM crashes on Linux?
What gives us knowing the version of UUID library besides it buggy?
Users still having no idea why it crashing,
and we, instead of including 'ensure fix #nnn in UUID C-library,
before installing Squeak' had to remove UUID plugin from use. Shame to
glorified Linux system with its cool package management tools, isn't?

The problem here, that even if you know where the problem is, you
don't have any control to fix it (you can't tell every user in the
world to upgrade their linux boxes to bug-free version of UUID
library).
And, if you are in control, then you don't have to worry about
versions, since all users will run the latest version of your stuff
anyways (by forcing check & load updates before starting application
;)

>> And anyways, you have to run some code to install the stuff in image,
>> and inevitably, have to deal with dependencies,
>> and different forks/dialects nuances. So, you still relying on code.
>> The only difference is where it written.
>
> In practice, the difference will be that your installer code will have
> additional dependencies that you're not aware off until it's too late. Could
> be simple stuff like using {} or #[] syntax. Oops, can't load *that* into
> Squeak 2.1 any longer. Or what if we require static typing in Visual
> Squeak++ 6.0? That's why these things are "specs", so that they are fully
> documented and understood and *not* randomly extended for convenience or
> otherwise.
>

Are you talking about standards here? Some of them could survive 20+
years. Smalltalk syntax almost not changed over this period.
And btw, how much of software you can run on modern systems, which
dated back to 70's?
I am agree, we need to stick with some standards. But evolution tells
us that only fittest survives. So, i doubt you'd wanna run the
software, written back in 70's, simply because there's a lot more
better stuff :)

>> And this is where 'declarativeness' standing in your way. There is
>> virtually infinite number of preconditions, which may influence the
>> installation procedure. Inventing, how to scribe them down using
>> declarative way IMO is doomed from the very starting.
>> The package maintainer , who writing the configs knows what works and
>> where, and so, he is to decide, what installation code should do, and
>> what not.
>
> I'm sorry but you're confusing issues here. There is no relationship between
> declarative specs and whether a package spec is written by the package
> maintainer or a third party. I'm fully in favor of having maintainers write
> those specs, but they can do that either way.
>

I'm not saying about who is maintainer. I am saying that with
declarations you are very limited in your config granularity.
For instance, how i can declaratively describe the process of
upgrading Sockets library , which should replace all existing Socket
instances by a new ones , while system is running and keep serving
requests?


>> So, i think, S/P is more enabling in this situation, than Metacello,
>> since its uses a list of instructions (tasks) - which can be anything,
>> not a declarative list of dependencies, which should be handled by
>> some uber-tool.
>
> Ouch! Depedency-driven build systems are not even remotely the same as
> configurations. Please don't compare the two. A dependency driven task
> system can almost certainly be used by a package management system, but the
> reverse is simply not true. The configuration describes the intended end
> state, the task system can help achieve the end state. So you can instruct
> the task system to load the proper entities (in fact, that's exactly what my
> builds script did) but you can't ask that task system what package versions
> it has loaded since it probably doesn't even know about that concept
> explicitly (at least not if the system is well-factored).
>

Yes, you need an extra knowledge in system , what is already installed etc etc..
Or what tasks are already made, and what's not.
I can gather this knowledge using the task-based system (see linux
Configure script(s)).
AFAIK, S/P tracking the installed stuff.
You run task, when its done - you recording 'this thing is loaded'.
Or: you telling to package-manager 'please load this package', oh..
and please, remember that you loaded it,
then please do that, then do that. And your package manager from
initially simple tool will evolve into horrendrous monster which tries
to control everything.


>> Sake is 'Make' - its configs is code with direct actions, not abstract
>> declarations. Its degree of declarativeness as high as you want to.
>> But you don't have to rely on some 'magic' in package-management tool
>> you using. If you want a highly customized install/deinstall
>> procedures, you are free to scribe them down. And if you installation
>> is simple - then why use package management at all - Installer is just
>> enough! :)
>
> Sure, if you don't need package management, there is no point in using it.
> However, that's a false premise - there are enough people (incl. myself) who
> *desperately* want one.
>
>> I think that if we take a look at SqS projects, which contains more
>> than 1 package to load, about 80% of them could be loaded using just
>> Installer.
>> And only 20% of them would require a more sophisticated stuff -
>> 'package management'.
>> So, why selling something, which in 80% of cases is just useless? I
>> don't buy it :)
>
> Or perhaps you're confusing cause and effect. The fact that we're unable to
> describe package dependencies in proper ways leads to the inability to
> actually rely on anything found in the various places. Why don't people use
> Squeakmap any longer? It served its purpose, then it started rotting because
> it didn't address several issues a package management system needs to
> address. Ditto with Universes (just a different set of issues). They all
> serve certain purposes but they all have failed to provide a reliable,
> long-term solution to package management in Squeak.
>
> I am pessimistic (and consequently quite hesitant in adopting it) in just
> the same way about Metacello. These issues don't apply to Installer, Sake or
> S/P for the reasons outlined above, but then these don't address the same
> set of issues.
>
> Cheers,
>   - Andreas
>
>



-- 
Best regards,
Igor Stasenko AKA sig.