prerequisiteNames

Hi,

I am experimenting with different package hierarchy organizations.

One thing that I would find useful is if a package's
prerequisiteNames/manualPrerequistes could either be package names or
pathnames ($ relative). If a pathname is used, that pathname could first be
checked for existence, and if it doesnt exist, the package name could be
split out of it.

Thanks,
Steve Waring

Hi,

In the spirit of having a quick hack it, I have appended a couple of changes
and additions to Package and PackageManager.

It certainly makes loading a "project" that has multiple packages across a
package hierarchy a more pleasant experience.

Standard disclaimers etc apply.

Steve
===

!PackageManager methodsFor!

load: prereqName path: path extension: extension loaded: loaded trail: trail
 "Private - Answer a Collection of Packages which have had to be loaded in
for the
 packageName argument to be successfully loaded in. The collection also
includes the
 contents of loaded."

 "Already installed or on the path?"

 | package expectedPathname actualPathname packageName |
 #sw.
 "SW: Check using the package name"
 packageName := self prereqPackageName: prereqName.
 ((self includesPackageNamed: packageName)
  or: [loaded includes: packageName]) ifTrue: [^trail].
 "SW: If the prereqName is a pathName and if it exists, use it to determine
the actualPathname"
 (packageName ~= prereqName
  and: [File exists: (FileLocator imageRelative localFileSpecFor:
prereqName)])
   ifTrue: [actualPathname := FileLocator imageRelative localFileSpecFor:
prereqName]
   ifFalse:
    [expectedPathname := File
       composePath: path
       stem: packageName
       extension: extension.
    actualPathname := (File exists: expectedPathname)
       ifTrue: [expectedPathname]
       ifFalse: [self errorPrerequisiteNotFound: expectedPathname]].
 actualPathname notNil
  ifTrue: [package := self loadPackage: actualPathname]
  ifFalse: [self errorPackageNotFound: packageName].
 ^self
  loadPrereqsForPackage: package
  path: path
  extension: extension
  loaded: loaded
  trail: trail! !
!PackageManager categoriesFor:
#load:path:extension:loaded:trail:!helpers!private! !

!PackageManager methodsFor!

prereqPackageNamed: aPreqName ifNone: absentBlock
 "Answer the <Package> held by the receiver whose name matches
 <readableString>, aPreqName , or, if there is no such package,
 the result of evaluating the <niladicValuable>, absentBlock.
 aPreqName can either be a $ relative pathName or a name."

 #sw.
 ^self packageNamed: (self prereqPackageName: aPreqName) ifNone:
absentBlock! !
!PackageManager categoriesFor: #prereqPackageNamed:ifNone:!accessing!public!
!

!PackageManager methodsFor!

prereqPackageName: aPreqName
 "Answer the packageName for aPreqName.
 A PreqName can either be a $ relative pathname or package name"

 #sw.
 ^(aPreqName includesAnyOf: '\/')
  ifTrue: [File splitStemFrom: aPreqName]
  ifFalse: [aPreqName]! !
!PackageManager categoriesFor: #prereqPackageName:!accessing!public! !

!Package methodsFor!

buildPrerequisiteNames
 "Private - Calculate and store the names of the receiver's prerequisite
packages."

 #sw.
 prerequisiteNames := self calculatePrerequisites collect:
     [:aPackage |
     "SW: may as well save them as pathnames"

     aPackage packagePathname].

 "Add any valid manual pre-reqs to the set"
 self manualPrerequisites do:
   [:prereqName |
   "SW: use a new method which expects prereqName to be either a name or
pathname"

   (self manager prereqPackageNamed: prereqName ifNone: []) isNil
    ifFalse: [prerequisiteNames add: prereqName]]! !
!Package categoriesFor: #buildPrerequisiteNames!operations!private! !

!Package methodsFor!

manualPrerequisites: aCollectionOfStrings
 "Set the <collection> of manually specified pre-requisite package names for
the receiver."

 | newPrereqs |
 #sw.
 newPrereqs := aCollectionOfStrings isEmpty
    ifFalse:
     ["SW: check for receivers name being either name or pathname"

     aCollectionOfStrings asSortedCollection asArray
      copyWithoutAll: (Array with: self name with: self packagePathname)].
 newPrereqs = manualPrerequisites
  ifFalse:
   [manualPrerequisites := newPrereqs.
   self isChanged: true.
   self resetPrerequisites]! !
!Package categoriesFor: #manualPrerequisites:!accessing!public! !

!Package methodsFor!

prerequisites
 "Answer a collection of <Package>s that must be loaded before the
 receiver can be loaded."
 #sw.
 "SW: use a new method which expects prereqName to be either a name or
pathname"
 ^self prerequisiteNames collect: [:packageName |
  self manager prereqPackageNamed: packageName ifNone: [_Uncommitted]]! !
!Package categoriesFor: #prerequisites!enumerating!public! !

Hi Andy or Blair,

Will the D5 final release have package prerequisites that are pathname
based?

In D4 I put a project's packages into one directory. In D5 I would like to
organize the packages into a hierarchy to take advantage of scoping.

The problem I having with this is that if I install a package with a number
of prerequisite packages, I am prompted to find the prerequisites in the
hierarchy. In D4 they would have been found in the current directory.

In D4 I also used a technique of creating an empty package and setting it's
manual prerequisites to a set of packages that made up a project. Again in
D5 this will not be effective as a prompter will still ask for the project's
package locations.

If package prerequisites are not going to be pathname based in D5, is there
a recommended approach? I did see in the D5 Beta1 a set of classes (I think
named DolphinOA*) that seemed to be responsible for building the base
hierarchy. Would you suggest doing something similar and including a class
which can then install the rest of the packages?

Thanks,
Steve Waring

"Steve Waring" <[hidden email]> wrote in message
news:[hidden email]...
> Hi Andy or Blair,
>
> Will the D5 final release have package prerequisites that are pathname
> based?
>
> In D4 I put a project's packages into one directory. In D5 I would like to
> organize the packages into a hierarchy to take advantage of scoping.
>
> The problem I having with this is that if I install a package with a
number
> of prerequisite packages, I am prompted to find the prerequisites in the
> hierarchy. In D4 they would have been found in the current directory.
>
> In D4 I also used a technique of creating an empty package and setting
it's
> manual prerequisites to a set of packages that made up a project. Again in
> D5 this will not be effective as a prompter will still ask for the
project's
> package locations.
>
> If package prerequisites are not going to be pathname based in D5, is
there
> a recommended approach? I did see in the D5 Beta1 a set of classes (I
think
> named DolphinOA*) that seemed to be responsible for building the base
> hierarchy. Would you suggest doing something similar and including a class
> which can then install the rest of the packages?

I'm glad your raised this issue (#762). We are sheltered from the problem
because our packages are (as you thought) loaded by some classes that are
responsible for constructing the image during our boot process, so we hadn't
really given it much thought. However it is clearly going to be pretty
annoying in practice to have to keep locating the pre-requisite packages
when they are not in the same directory (which of course is the point of the
new hierarchical structuring). To this end I have adopted a similar scheme
to that you suggest. The differences are that:
1) The prerequisite package paths are relative to the package itself, rather
than being image relative. This should help if one decides to move an entire
package hierarchy to be rooted in another folder than when the package was
originally saved. As before the user will still be prompted to locate a
pre-req that is not either at the relative path, or in the same directory as
the package being loaded.
2) The relatively pathed pre-requisite names are only present when the
package is in its pre-loaded state.

The only downside of this that I can think of is that it will probably
prevent D5 packages loading into D4. However it will be very easy to patch
D4 to get around this.

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:[hidden email]...

> 1) The prerequisite package paths are relative to the package itself,
rather

Hi Blair,

Thanks for this change, it is working well for me in Beta3.

Thanks,
Steve