Package Universes?
Locked
 
|
Hi all, Back in the Jurassic period, somewhere around Squeak 3.7, there was something called “Package Universes” which I think was done by Lex Spoon, although my memory is a little hazy. It attempted to simplify package management by reifying the concept of groups of packages which worked together - a ‘Universe’. Each Squeak image would then be within a Universe, and could be assured that packages wouldn’t conflict in that context. The Package Universe browser isn’t in the latest Squeak, so I’m assuming that the approach was abandoned at some point in the last decade or so. Did Lex or anyone do a post-mortem on why the Universes approach didn’t work for Squeak package management? I can’t immediately see what replaced it in the current Squeak, but I haven’t used Squeak for a while so don’t really know what I’m doing… Cheers Russell |
|
|
|
|
|
In reply to this post by Russell Allen
Universe's needed tools to be maintained and a server if I recall correctly. Sake/Packages imported the universe's dependencies into class methods and was very effective indeed, supported unloading and loading. http://wiki.squeak.org/squeak/5953 Keith On 26 Apr 2020 8:33 am, Russell Allen <[hidden email]> wrote:
|
|
|
The (now 10 year old) theory was to have a clear way to declare packages, for loading and unloading with their dependencies. Then more parts of the monolithic squeak image could be seamlessly moved into optionally unloadable packages. (Argueably The opposite of traditional package management). I.e A test release could even contain all of the packages available, and the user could unload the ones they didn't want. An alternative basis for developing the image was defined and used for a year This consisted of defining patches, mainly bug fixes enumerated by the mantis bug tracker. Thus the next release would always consistently be, the previous release + bug fixes + package definitions - package unloads. The idea was that the development of the image was to be changed from being based on a moving target (an always evolving trunk repository with multiple contributors tripping over each other) to a different model. The new model was based on a known fixed target, namely the previous release, plus an evolving set of blessed fixes, and package definitions that could be tested by everyone in their production images. Thus any project or fork would have the ability to keep up to date with latest by cherry picking the relevant fixes, and package definitions, into their current build or working image, rather than having to wait for the next fanfare release and port their code once every 2 years. This process was designed at the outset to enable parallel development of multiple forks/images, anticipating that as more packages get unloaded from the monolithic image, their maintainers need to be able to maintain those packages for multiple destinations. Via sake/packages You could publish a package together with, patches for Pharo, or cuis or cobalt, or even squeak 3.7 and all of those targets could use the same process. (via Installer) A limitation of squeakmap and universe's was that each package definition is centrally managed. Sake/Packages on the other hand allowed each user, fork, or project to maintain their own subclass of package definitions. Thus the knowledge of what works where, and what patches are needed for deployment in each fork/project is provided by the actual users. Package maintainers can see how their package is actually used, in different contexts. E.g. magma when used with seaside, was not a use case that Chris regularly tested himself, but the visibility of how it is used provides feedback to the package maintainers. The driving motivation for this was a realisation that it was hard for any commercial work to keep up to date, and larger projects inevitably got left behind in an older image, because the previous release teams were too busy making a great new revolutionary incompatible release, rather than supporting the evolution of what is already in use. This killed many potentially interesting projects. I myself gave up on a pier/seaside/magma based web shop (before shopify.... Sigh) and you could argue that gjallar was another victim. Since the return to trunk based development, it became clear that squeak wasn't ever going to be a viable platform for commercial use because maintaining simple packages was being made harder not easier. K. On 28 Apr 2020 5:01 am, [hidden email] wrote:
|
|
|
Just to finish describing the vision. An important part of this vision was to enable package loading and unloading to be atomic. Thus the ultimate goal would be to enable morphic to be unloaded atomically, and replaced atomically with an alternative UI framework (morphic 3?) Prior to bringing up the UI. At the time I was never able to manage to get the atomic loader working with traits. This was probably due to what some characterised as my "mediocre" programming skills. In truth my skills are more in the higher level process design, than down in the bits. I have no idea if atomic loading/unloading ever came to fruition but it would have been a fundamental part of moving squeak on from the morphic etoys tangle that was, and a perfect compliment to sake/packages. Which incidentally also worked in cuis and pharo equally well because it didn't depend on any UI. K. On 28 Apr 2020 5:43 am, [hidden email] wrote:
|
|
This vision also depends on untangling all those cyclic dependencies between Morphic and the base system (i.e. Graphics). Best, Marcel
|
|
|
Hi all-- Marcel writes: > This vision also depends on untangling all those cyclic dependencies > between Morphic and the base system (i.e. Graphics). Of course, even identifying those dependencies is hard. I think the least difficult way to do that is test-driven. Remember which methods are touched and when, as a side-effect of running unit tests on instrumented VMs. -C -- Craig Latta Black Page Digital Amsterdam :: San Francisco [hidden email] +31 6 2757 7177 + 1 415 287 3547 |
|
|
In reply to this post by Russell Allen
> On Sun, Apr 26, 2020 at 05:33:46PM +1000, Russell Allen wrote: >
> > Did Lex or anyone do a post-mortem on why the Universes approach didn’t work for > > Squeak package management? > > > > I can’t immediately see what replaced it in the current Squeak, but I haven’t used > > Squeak for a while so don’t really know what I’m doing… > > Hi Russell, > > Information on Package Universes is https://wiki.squeak.org/squeak/3785 and the complete code repository is at http://www.squeaksource.com/universes > > Universes was created by Lex Spoon, and Damien Cassou was also a major contributor. It was part of the Squeak image for many years, but we decided to remove it in 2015 because it was not being maintained and was no longer fully functional at that point. It should be possible to load it in Squeak 5.3, but you should expect to need to resolve some problems. In my opinion, Package Universes was (and still is) a well-conceived idea, and it's too bad that it never really gained traction. If you manage to do something good with it, please report back :-) > > Dave Thanks guys for the responses. The Universes code from SqueakSource loads into a 5.3 image fairly well, with only some deprecated morphic methods to handle. Of course the Universe server is long gone, so I haven’t tested it yet. It seems as if the core concept and code is very simple, any complexity really comes from the way in which the package universe code defines its own server (with a basic concept of security and permissions) and interactions with that server. It seems to me that a rewrite could separate the making and publishing of universes out into separate tools and end up with a very lightweight system. Reading through the resources, my conclusion is that it should be considered in the same category as apt for Debian or homebrew for MacOS, rather than hackage or npm - that is, it is a tool for managing multiple ‘applications’ in an image you live in rather than a tool for a developer assembling components to be compiled into single application/image to be used as a deliverable or app server. Cheers Russell |
|
|
On Fri, May 01, 2020 at 09:37:00AM +1000, Russell Allen wrote:
> > On Sun, Apr 26, 2020 at 05:33:46PM +1000, Russell Allen wrote: > > > > Did Lex or anyone do a post-mortem on why the Universes approach didn???t work for > > > Squeak package management? > > > > > > I can???t immediately see what replaced it in the current Squeak, but I haven???t used > > > Squeak for a while so don???t really know what I???m doing??? > > > > Hi Russell, > > > > Information on Package Universes is https://wiki.squeak.org/squeak/3785 and the complete code repository is at http://www.squeaksource.com/universes > > > > Universes was created by Lex Spoon, and Damien Cassou was also a major contributor. It was part of the Squeak image for many years, but we decided to remove it in 2015 because it was not being maintained and was no longer fully functional at that point. It should be possible to load it in Squeak 5.3, but you should expect to need to resolve some problems. In my opinion, Package Universes was (and still is) a well-conceived idea, and it's too bad that it never really gained traction. If you manage to do something good with it, please report back :-) > > > > Dave > > Thanks guys for the responses. > > The Universes code from SqueakSource loads into a 5.3 image fairly well, with only some deprecated morphic methods to handle. > > Of course the Universe server is long gone, so I haven???t tested it yet. > > It seems as if the core concept and code is very simple, any complexity really comes from the way in which the package universe code defines its own server (with a basic concept of security and permissions) and interactions with that server. It seems to me that a rewrite could separate the making and publishing of universes out into separate tools and end up with a very lightweight system. > > Reading through the resources, my conclusion is that it should be considered in the same category as apt for Debian or homebrew for MacOS, rather than hackage or npm - that is, it is a tool for managing multiple ???applications??? in an image you live in rather than a tool for a developer assembling components to be compiled into single application/image to be used as a deliverable or app server. > > Cheers Russell > I think that your conclusions are right on target. Debian package management is a good analogy. Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |