Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Package Universes
Last updated at 1:26 pm UTC on 27 November 2015
In Squeak 5.0 the Universes browser has been removed as it was no longer functional. The Squeak 5.0 release contains the Universe package though. It was removed from the trunk on Nov 27th, 2015.


September 2007


Package universes are an approach to supporting no-hassle installs via a package loader. See Why Packages Universes Exist for an argument that package universes exist. This page describes how Lex Spoon's "Universes" toolset uses explicit package universes in order to get automatic installs working reliably.

Links:

Development Universe

To try it out, install "Universes" from SqueakMap into a current image. Be sure to install any prerequisites you need. Then "open...Universe Browser". You'll have to press the "update list" button the first time you load the universe browser, and then after a few seconds you will see a list of packages available in the default "Development" universe, a wide-open index-server universe that anyone can edit.

Try scrolling down to the "BFAV2" package, selecting it, and then pressing the "select package" button. You will notice that the text (install) appears next to the item now – that means that the package has been flagged for installation. If you scroll down in the list, you will see that HTTPClient has also been flagged for installation; this happened because BFAV2 depends on HTTPClient.

Next click the big "INSTALL" button at the bottom of the window, and the Universe Browser will download BFAV2 and HTTPClient and install them for you.


How to Post and Edit Packages

If you want to post or edit a package, you need to use the Universe Editor. Use the "open" menu to open a universe editor.

You will initially need to create an account. So, type in a username and password, and then press the "create account" button. You will be asked to fill in an email address; leave it blank if you prefer, but this email can be used in case your password is forgotten.

New you can press either "new package" or "new package version", depending on whether you want to add an entirely new package or you'd prefer to post a new version the currently selected package. A new window will pop up and you can fill in the fields that describe your package. Click "submit" when you are finished.

If you see a package that you think is yours, then go ahead and feel free to update it. If you are the first to try and edit any information about packages with a particular name, then the development universe will assign that package name to your account.

If you are Behind a Firewall

If you are behind a firewall and the above does not work, then you may still be able to connect over HTTP. Simply set up your HTTP proxy as described on Getting updates behind a firewall. You will only be able to retrieve packages this way, however; to post packages, you need to be able to make a TCP connection to the server.

What's a Package Universe?

A package universe is a set of packages plus policy on how the set is allowed to change over time. It is called a universe, because each Squeak image will exist within one such universe, and each user will operate within one such universe at a time. A universe provides answers the question "what exists?"; anything outside a user's current universe is completely ignored.


Why Bother with this Universes Stuff

The short answer is that it seems to work. Universes exist, and it seems to work well to manage them explicitly. Here are some things we can handle, if we and our software explicitly discuss package universes.


Simple Dependencies Work


By limiting the number of packages that are in the universe, simple dependency approaches are sufficient. There is no need to track which individual versions of which packages are compatible with eachother, because people working in any given universe will tend to use the newest versions available within that universe.

As a result, dependencies like "A depends on B" are usually fine. If the main author of B has developed B into a form that is incompatible with A, then that package will simply not be posted into the universe. And even if the newest A and newest B are incompatible, the situation can be treated like any other bug: fix A, fix B, or reject one of the two from the universe. Once one is committed to operating within one universe at a time, dependency management can be greatly simplified.

Without the context that a universe supplies, such simple dependencies don't work. The package-browsing tool will see not only packages destined for your current image, but every other package for every other image in the world.

Tagging packages with specific Squeak versions comes close, but runs into difficulties with policy, as described below.

Update Policies


It is well known that some users prefer the newest software and others prefer the most stable. The packaging approaches described so far seem to by planning to make the package-installer software customizable by the individual users in order to select these preferences. There is no specific mechanism, however, that has yet been proposed. It's always been a problem of the future.

The perspective that package universes give is the following: if you want stable packages, then you probably want all of your packages to be stable. Thus, it makes sense to define and maintain a universe of stable packages. Likewise, if you have a few new under-development packages, you probably want to go ahead and try out the new versions of most packages. Thus, it also makes sense to define a wild 'n woolly development universe.

Package universes give an easy way to organize and manage these different update policies. You can just say "this universe works like this" and "that universe works like that".

Additionally, package universes give a place to implement these different policies. If you want to build a stable universe like Stable 3.7 Universe, then you can let the maintainer of the universe implement barriers to entry which match the desired policy. If, instead, you use a Catalog of Everything and simply add universe tags to each package, there is no place to implement this policy; any developer can add and remove their packages to any universe, as they desire.

Expected Content

In addition to different policies, some universes will simply contain stuff that is different. Different universes provide a convenient way to manage different content alltogether. While I might like to put my collection of home videos on the internet and accessible to my family, the rest of the world would prefer not to even be concious of these terribly boring things (or, they'd like to see THEIR home videos). While most of the world might want to have DVD software available publically, such software can likely not be posted to any server that is in the United States.

Package universes provide a natural way to manage these different kinds of expected content. No matter how benevolent and permissive any central Squeak authority is, there is sure to be some content that is not appropriate for the general public but that would make a lot of sense to have available for those that want it.


Mixin Universes

The desire for mixin universes follows from the above desires. Much of the unusual content that people provide is relatively agnostic about Squeak version, and can be combined with other such unusual content in arbitrary combinations. A mixin universe is a set of packages that can be mixed into a large number of other universes without breaking too much. Package universes provide a simple way to think about these mixins: you create larger universes simply by taking the union of the packages in two separate universes.

Theory aside, note that Debian supports mixin repositories, and their http://www.apt-get.org meta-catalog lists hundreds of repositories that are at least mostly intended as mixins.


Shorter Names

By limiting the number of packages that are available in a universe, names can often be shorter than they would otherwise need to be. A universe provides context. In a development universe for Tweak, one doesn't need to name the package "TweakBase", but can instead just say "Base". Everyone will understand that the "Base" package of the "Tweak" universe is the base package of Tweak. On the other hand, it doesn't make sense to post a package named "Base" on SqueakMap. No one will understand what it is the "base" of.


Setting up a Local Mixin Universe

If you want to use package universes to manage the local packages for your work group on some project, then you can do so. The general approach is:
  1. set up a universes server on some machine you have access to
  2. set up your images to use a "compound universe", which combines your local universe plus one of the public universes (e.g., the development universe, or one of the stable universes)

To set up your own universe server, you need to do the following:
  1. Load Universes into a Squeak image.
  2. Create a UStandardUniverse object which describes your universe. Look at the "well known" category of class methods in UUniverse to see how to do this.
  3. Create a UServer object which refes to your universe, and which has the policy you want.
  4. Create a directory for the server to save its snapshots in.
  5. Tell your UServer to save a snapshot into that directory; now you have a universe on disk to work with.
  6. Run the following code:
 	Smalltalk snapshot: true andQuit: true.
	server _ UUniverseServer forSaveDirectory: (FileDirectory on: '/PATH/TO/YOUR/SNAPSHOT/DIRECTORY').
	server openStepperMorph.
	server startListening.

Now you can start up a universes server by just running that image.

To see how to set up your images to use this server, look at UUniverse's exampleCompoundUniverse method.

This process is a lot more complicated than it needs to be.... But so far it seems like a low priority, so no one has worked on streamlining it.


Comments