Here are the package requirements I've been hearing in these threads and are congruent with my own:
1) Easy-installation. One-click installation of multi-package software systems, including, if necessary, execution of install scripts and local deployment of resource files. 2) Easy-publication. One-click deployment of multi-package software systems, including install scripts and resources). 3) A full SCM collaboration system, with diffing, merging and distribution across multiple repositories. 4) Ability to plug into any other existing or future packaging system.
Requirement #3 is met by Monticello. Requirements 1, 2, and 4, used in the context of an appropriate lifecycle, can be met solely with the existing Monticello and SqueakMap tools we have today. And there are just two steps to get there, one of which is just a change of *thinking*!
step 1) Assimilate this thought: "Anyone integrating multiple programs (packages) into a single image is doing development." step 2) Humans make all SqueakMap packages one-click loadable and only publish one-click-loadable packages going forward on SqueakMap. Do this via the SAR install script, making calls to other packaging systems as necessary (satisfying requirement #4).
By doing just these two things we don't need any other tools and SqueakMap doesn't need dependencies to meet the four requirements. At the same time, other tools can be used and called from the SAR script if desired.
SqueakMap is the "Squeak showroom" place for exploring what packages are about. We only expect SqueakMap to load a *single* package into the image which it says is compatible. Of course, we know we can load more than one, but the included Test Suites provide my comfort on whether everything still "works".
We don't worry about conflicts between package versions loaded from SqueakMap because that requires deliberate package integration in which you use Monticello, not SqueakMap. The maintainer will update his dependency list soon enough if we make publishing to SqueakMap easy. I added a "BuildSar" button to Monticello Configurations browser so I could at least build the SAR in one-click, which I then have to manually upload to SqueakMap.
- Chris
Put another way, if we use SqueakMap solely as a tool for consumption of software, and Monticello for production (and consumption) of software, improve the bridge between the two (publishing) and we're basically Done..! Seriously, what else is missing?
Chris Muller wrote:
Put another way, if we use SqueakMap solely as a tool for consumption of software, and Monticello for production (and consumption) of software, improve the bridge between the two (publishing) and we're basically Done..! Seriously, what else is missing?
I agree, this can be a easily achievable base for evolving further.
I have quite some time in mind to start with a first step: a SqueakMap web "uplift", that is, a reimplementation of map.squeak.org to be more user friendly but also more fresh looking and modern.
We can then make the next step in that evolution: adding a good dependency support, with merging Universes approach or somehow different. If we merge that part of Universes which seems to work really well, we did a first unification: between SM and Universes. End user will now be happy, installation will be as simple as possible: one click.
Next step is better and as user friendly as possible integration with Monticello as in-image tool for package and version control. This would be preferable for publishers.
Another step would be adding/merging Sake/Packages and LPF, at least as I understand Keith's work.
Evolution and unification of existing tools, that's my proposal, not revolution and doing everything from scratch again and again. Well, for experimental purposes revolutionary approaches are welcome, but as we can see, those projects loose breath somewhere in the middle. But we can incorporate ideas from that experiments in our evolutionary tools. That's how I see things.
Janko
On Fri, Jun 27, 2008 at 11:39 PM, Chris Muller asqueaker@gmail.com wrote:
We don't worry about conflicts between package versions loaded from SqueakMap because that requires deliberate package integration in which you use Monticello, not SqueakMap. The maintainer will update his dependency list soon enough if we make publishing to SqueakMap easy. I added a "BuildSar" button to Monticello Configurations browser so I could at least build the SAR in one-click, which I then have to manually upload to SqueakMap.
I'm not sure I understand, is this deliberately ignoring all integration problems ?
What if you need two packages from separate developers, they have to agree on what they include on each side ?
I'm not sure I understand, is this deliberately ignoring all integration problems ?
No, I am saying use Monticello for handling integration problems. If you load one multipackage software system (MPSS) from SqueakMap and another different MPSS has a earlier version of one of the same prerequisites, you open up a Monticello browser, load the specific one you want, run the test cases, etc.
If these two MPSS's really have a purpose together in the same image then you are developing yet a new MPSS based on these other two. Monticello is the appropriate tool for assisting with that integration (not SqueakMap).
Once you've got them together you can easily post your own *new* MPSS to SqueakMap which combines the function of the other two.
What if you need two packages from separate developers, they have to agree on what they include on each side ?
Not at all. You cherry-pick what YOU need from each for your stuff.
On Sat, Jun 28, 2008 at 8:16 AM, Damien Pollet damien.pollet@gmail.com wrote:
On Fri, Jun 27, 2008 at 11:39 PM, Chris Muller asqueaker@gmail.com wrote:
We don't worry about conflicts between package versions loaded from SqueakMap because that requires deliberate package integration in which you use Monticello, not SqueakMap. The maintainer will update his dependency list soon enough if we make publishing to SqueakMap easy. I added a "BuildSar" button to Monticello Configurations browser so I could at least build the SAR in one-click, which I then have to manually upload to SqueakMap.
I'm not sure I understand, is this deliberately ignoring all integration problems ?
What if you need two packages from separate developers, they have to agree on what they include on each side ?
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On Sat, Jun 28, 2008 at 5:42 PM, Chris Muller asqueaker@gmail.com wrote:
I'm not sure I understand, is this deliberately ignoring all integration problems ?
No, I am saying use Monticello for handling integration problems. If you load one multipackage software system (MPSS) from SqueakMap and another different MPSS has a earlier version of one of the same prerequisites, you open up a Monticello browser, load the specific one you want, run the test cases, etc.
If these two MPSS's really have a purpose together in the same image then you are developing yet a new MPSS based on these other two. Monticello is the appropriate tool for assisting with that integration (not SqueakMap).
Once you've got them together you can easily post your own *new* MPSS to SqueakMap which combines the function of the other two.
So basically, either users duplicate the integration work for combinations of packages not prepared before, or they publish their combination for others to reuse, resulting in as many new specialized combination packages ?
First, this kinda defeats the purpose of a package system to me, and second, what difference does that make w.r.t MC configurations?
On Sat, Jun 28, 2008 at 12:00 PM, Damien Pollet damien.pollet@gmail.com wrote:
So basically, either users duplicate the integration work for combinations of packages not prepared before, or they publish their combination for others to reuse, resulting in as many new specialized combination packages ?
First, this kinda defeats the purpose of a package system to me, and second, what difference does that make w.r.t MC configurations?
I am by no means a version-integration expert, but Colin Putney gave a nice presentation on Monticello 2 at Smalltalk Solutions. I believe his words were something like, "If you take one thing away from this presentation, remember that the success of a packaging system is based on how well it can MERGE." (Complete with a big, yellow, traffic merge sign).
Unfortunately, his slides are not yet available at:
http://www.stic.st/stic?content=sts08Detail#june21Detail
However, he demonstrated some of the abilities of Monticello 2 based on what he called a "much simpler" merging (versioning?) methodology.
I'm sure I messed something up in translation, but what he said made sense to me and might be worth bringing into the discussion if possible.
Rob
... Once you've got them together you can easily post your own *new* MPSS to SqueakMap which combines the function of the other two.
So basically, either users duplicate the integration work for combinations of packages not prepared before, ...
If a combination wasn't prepared and published before then, by definition, that combination hasn't been meaningful enough as a singularity for anyone to have performed such integration. Since it hasn't been done before, there's no duplication of work.
.. or they publish their combination for others to reuse, resulting in as many new specialized combination packages ?
First, this kinda defeats the purpose of a package system to me, and
You forgot to do step 1. Reduce your expectation of SqueakMap from being a "packaging system". That's Monticello. Instead, SqueakMap is just a showroom from which you expect to be able to *easily* review and learn about a package. This is why I encourage SqueakMap packages to not be shy about pop-ups to introduce the package to the user, even utilising Squeaks multimedia capabilities in an engaging way if possible. Talk about on-line documentation and the attraction that would be for new users (and me too!).
I really like what OSProcess does when it loads up, showing you the current VM process and some docuementation.
second, what difference does that make w.r.t MC configurations?
A one-way bridge from MC to SqueakMap would not be difficult or time-consuming to build. MC Configurations has been useful for me in that bridge because it allows one-click generation of a self-installing SAR (all packages in order) that I simply upload to SqueakMap. Of course, it might be nice to have a one-click including SqueakMap upload directly from the image...
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On Sat, Jun 28, 2008 at 7:25 PM, Chris Muller asqueaker@gmail.com wrote:
... Once you've got them together you can easily post your own *new* MPSS to SqueakMap which combines the function of the other two.
So basically, either users duplicate the integration work for combinations of packages not prepared before, ...
If a combination wasn't prepared and published before then, by definition, that combination hasn't been meaningful enough as a singularity for anyone to have performed such integration. Since it hasn't been done before, there's no duplication of work.
Maybe. But ideally a package manager doesnt even require the work to be done. Each package *locally* defines what it needs and what it provides, and "integrating" is just choosing something else than the default when there are several possibilities to fulfill a dependancy, effectively making a new adhoc composition.
You forgot to do step 1. Reduce your expectation of SqueakMap from being a "packaging system". That's Monticello. Instead, SqueakMap is just a showroom from which you expect to be able to *easily* review and learn about a package. This is why I encourage SqueakMap packages to not be shy about pop-ups to introduce the package to the user, even utilising Squeaks multimedia capabilities in an engaging way if possible. Talk about on-line documentation and the attraction that would be for new users (and me too!).
Then this is useful only once per user, at the first installation. IMHO this would be better fulfilled by having nice (read HTML with links and images) class/package comments in the image and a way to navigate them like a manual rather than randomly picking classes and methods. SqueakMap should also present these comments online so you can see what the package does before installing it.
However, this is orthogonal to the need to say "I need X" and have the system automatically install all the necessary, while not forcing people to maintain each and every used combination separately.
Ex. Pier needs Seaside. If there is a new release of Pier, the Pier developers update the Pier package and nothing more. If Seaside gets upgraded, the Pier package should *not* have to change/be regenerated/whatever until the Pier code is updated.
I really like what OSProcess does when it loads up, showing you the current VM process and some docuementation.
Do you like to close the same 12 windows each time you rebuild an image or upgrade the package ? What when OSProcess gets installed because it is used behind the scenes by the actual thing you want ?
I really like what OSProcess does when it loads up, showing you the current VM process and some docuementation.
I really hate it... at the end of building a large image you have to go around closing all of these unwanted windows.
For which I had to write a package - squeaksource.com/Scripter
best regards
Keith
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Damien Pollet -
Janko Mivšek -
Keith Hodges -
Rob Rothwell