A small variation to use provides / requires
Locked
 
|
In complex packages that have many prerequisites, it is sometimes uncomfortable place them in the package. One way I found particularly useful is to put together a package installer that contains the prerequisites only (a single class used to build the package) as in Swazoo.
The example is in https://github.com/garduino/Cuis-Smalltalk-Swazoo --> Swazoo-Installer.pck.st
Then, to install Swazoo you must evaluate: Feature require: 'Swazoo-Installer' and from others installer packages that require Swazoo, you only must add the #requires for Swazoo-Installer, and the real code packages (Swazoo and others related to network in this case) remain untouched and can be used from different installers.
Reshaping the Aida installer right now :) Saludos / Regards,
Germán Arduino www.arduinosoftware.com _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
On Sat, 24 Aug 2013 17:44:30 -0300
Germán Arduino <[hidden email]> wrote: > In complex packages that have many prerequisites, it is sometimes > uncomfortable place them in the package. ... > Then, to install Swazoo you must evaluate: Feature require: > 'Swazoo-Installer' and from others installer packages that require Swazoo, > you only must add the #requires for Swazoo-Installer, and the real code > packages (Swazoo and others related to network in this case) remain > untouched and can be used from different installers. This confuses me. Why would I not just !requires: 'Swazoo' 1 0 nil! "Feature require: 'Swazoo'" for any packages that require Swazoo? Say I create a set of unit tests for Aida, and I want to pull in the networking tests as well. I should be able to do something like !provides: 'Aida-Tests' 1 0! !requires: 'Cuis-NetworkTests-UUID' 1 0 nil! !requires: 'Cuis-NetworkTests-RFC822' 1 0 nil! !requires: 'Aida 1 0! Then I just Feature require: 'Aida-Tests'. and everything I need gets loaded in the right order. If I don't want the network tests, I just do !provides: 'Aida-Tests' 1 0! !requires: 'Aida 1 0! So Feature require: 'Aida-Tests'. provides everything required to run Aida unit tests. Why create a separate 'Aida-Tests-Installer' ??? I think it must be more simple than a separate installer so I will not be confused. -Ken _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
|
|
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.
But, it's only an opinion :) 2013/8/25 Ken Dickey <[hidden email]>
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: A small variation to use provides / requires
|
|
On 8/25/13, Germán Arduino <[hidden email]> 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. 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 [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: A small variation to use provides / requires
|
|
P.S. Maybe it is an issue if we look at portability to other Smalltalk dialects.
On 8/25/13, H. Hirzel <[hidden email]> wrote: > On 8/25/13, Germán Arduino <[hidden email]> 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 [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: A small variation to use provides / requires
|
|
In reply to this post by Hannes Hirzel
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 <[hidden email]> wrote:
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by garduino
> .. 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,... My recollection of a discussion with Dave Simmons about Smalltalk Agents is that one can associate revision information with selector lookup/dispatch to allow for multiple, different versions of software to run in the same image. I believe this was done in SmalltalkAgents. This is very useful when developing so that the debug tools can use the old, stable version when debugging new development tools. [This is also done in some Scheme systems]. The current provide/requires allows for this by supplying the version & revision information. It is true that we currently do not make use of this in package checking, but the code would be easy to add. The guide is that we try to do useful things in the most simple way we can and then make things more smarter and more complex when and if we need to. Having a package specify its direct requirements helps here. If one separates the requirement description from the package, then the package and its description can get out of synchronization -- the wrong version information could be used. One more thing I have to track and update. One more thing to go wrong. This is less of a danger when the description is part of the package. IMHO, package management is easier. When I change a package, the revision number is incremented so when the package is saved I know it is a new revision. If two packages have conflicting requirements, each package requiring other packages with incompatible versions, then the code can check and deal with that. Incompatible requirements are like missing requirements -- it means that you can't safely use the mix of code packages together. It is much better to know this before the code is loaded, no? It would help me if Feature require: 'Swazoo' Actually loaded Swazoo... $0.02 -- Ken [dot] Dickey [at] whidbey [dot] com _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
|
|
HI again! This sort of discussions/opinions are aproximately the same that happened and originated Monticello/Metacello/etc. Each option have its own strengths and weakness but, with the current state of provides/requieres in Cuis, I still think that is a better approach to separate the req's from the packages with the code. (I know that this option have also the drawbacks that you mentioned).
But still I think that I gain flexibility and reuse of the packages, separating the requirements from the real code packages. Time will say when we advance to a more complex situations with different versions of each package, but I really not think that is an easy stuff.
As I've said before, is just an opinion and I will think about a bit more. Each option have its own strengths and weakness 2013/8/25 Ken Dickey <[hidden email]> > .. when I've a package that have several req and at the same time this Saludos / Regards,
Germán Arduino www.arduinosoftware.com _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Hi again! After a bit of talk with Ken and Juan and taking in account that the packages without prereq (when they are moved to an installer package) get broken and fail when a use try Feature require: 'mypackage', I'm reverting the installer packages of Swazoo and Aida to it's original state, that means each one with it's own prereq (Assuming that the duplication of prereq between different packages is not a problem).
Ken: I'm closing the issue in Swazoo, with this solution and the Aida problem is solved also with the original form of installation, but take in account that Aida really take a long time to load in a Cuis image (and you can see the repetition of this cycle scan, process, etc).
2013/8/25 Germán Arduino <[hidden email]>
Saludos / Regards,
Germán Arduino www.arduinosoftware.com _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |