[Cuis] A small variation to use provides / requires

[Angel Java Lopez]

Well, I don't know about Cuis features

But regarding:
'If you look at other languages the concept of stating at the beginning
of a package what it requires as prerequisite is quite common'

In other language, you have require, import, using commands or something
alike, not as prerequisite, but as declaring "Now, I need, in this file,
package,...  these implementations/namespaces/packages/etc"

So, in one file, you can have requires (ie Node.js) but the prerequisites
are usually in other files, out of code (maven, nuget, npm, gems, pip,
etc...)

So, at code time, you import in your namespace what you need.

At install time, you run other command to install the dependencies, maybe
using a repository, with online access

In this way, you can specify also the version, not in code, but in install
files

I like this separation of concerns (notably, npm, node package manager can
download dependencies BY PACKAGE, so P1 can use P2 version 0.1.0, and other
package in the same application, say P3, can use P2 version 0.0.9)

And deployment on stacks like Heroku, also likes this separation of
concern: declaring the dependencies is out of code.

But I don't know about Cuis or Smalltalk in general. You have images, live
objects, etc...  My own implementation started to use npm as repository.

Angel "Java" Lopez
@ajlopez



On Sun, Aug 25, 2013 at 12:41 PM, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> On 8/25/13, Germán Arduino <garduino at gmail.com> wrote:
> > Hi Ken:
> >
> > I'm not saying that my approach is the best to all cases, probably not in
> > the simplest situations.
> >
> > But when I've a package that have several req and at the same time this
> > package is a req of more than 1 different package, that at the same time
> > might have different req between them and coexist in the same image, I
> > think that may be more neat not to mess the real package (the one that
> > contains the real code) with prereq, and isolate them in an installer
> > package.
> >
> > My feeling is that not having lot of #requieres hardcoded in the package
> > that have the real code of its domain may bring more flexibility in the
> > reuse at installation level.
> Maybe. But I see the 'provides/requires' information as part of the
> package.
>
> If you look at other languages the concept of stating at the beginning
> of a package what it requires as prerequisite is quite common. It is
> not so common in a Smalltalk context but it is not so common as well
> to use an exiting version control system. Both things
> - going for packages which explicitly state what they need and
> - using a well known version control system like github
> is fine for me.
>
>
> -- Hannes
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20130825/34be5331/attachment-0002.html>