too many packages created

Unhappily, this will not do.

1- you can't defpackage like that and expect to upgrade or even merely re-load without an error. The discrepancy in exported symbols will cause an error on many implementations.

2- you can't rely on cl-user for the symbols used in the boostrapping let form, so either we do some clever make-package in an eval-when, or we do the trivial defpackage. Packages should be relatively cheap to create. Aren't they? If they are considered expensive, then we could use make-package. cl-launch uses a conditional make-package this way.

3- I carried over a separate asdf-utilities package from ASDF 1, so that one could use the utilities independently from the system interface. But a long prefix makes it not very usable indeed. Maybe it's simpler to just export everything from ASDF (and keep the old name for backward compatibility? Or does noone rely on it?)

upgradability/reloading has a very low priority to me as a user.
my model is that asdf comes with the implementation, offers some interface, and is never upgraded unless I upgrade the implementation.

> you can't rely on cl-user for the symbols used in the boostrapping let form

huh? why can't you just assume ansi cl compatibility?
cl-user uses cl as per the standard - is there an implementation which does not have that?

> Packages should be relatively cheap to create

yes. the issue is more aesthetical than anything else.
clisp comes with 20 packages. asdf creates 3 more. I think this is excessive.
I don't see why a single "facility" would need more than 1 package.

> Maybe it's simpler to just export everything from ASDF (and keep the old name for backward compatibility?
> Or does noone rely on it?)

I think a vast majority of your users use asdf for what it is: defsystem facility.
people who want inter-implementation portability or extra (non-ansi) functionality use specialized packages.
I don't think it is wise to go down the slippery slope of feature creep. just offer a good defsystem; not

1- upgradability is essential as a way for users to be confident they only need to make their software work against one version of ASDF, the latest released one. Outside this promise lies madness. Read my ILC2010 paper (when it's out), or my article "Software Irresponsibility"
http://fare.livejournal.com/149264.html

2- one thing is being able to use symbols from :cl, another thing is being guaranteed that you can bind and fbind symbols using let, let*, flet and labels without be caught by any interesting special or constant declaration or package lock. Running the big bootstrap form from cl-user is a bad idea. But yeah, if ASDF-BOOTSTRAP is a problem, I could try using a conditional MAKE-PACKAGE to bootstrap ASDF from a simpler version of itself. Sigh.

3- I can see a point in both sides. I probably wouldn't have created this ASDF-UTILITIES package if something similar hadn't existed since ASDF 1 days. I think this discussion ought to be on asdf-devel.

upgradability is trivial: (delete-package "ASDF") should remove all traces of ASDF.
now you can just (load (compile-file "asdf.lisp")) and be done.

nevertheless, asdf should aim not for "constant upgradability" but for "eventual stabilization".
people do not upgrade their gnu make to the latest version before they can build a package.
make is stable, like bash or ls. it is there.

similarly, asdf should stabilize _soon_. instead of maintaining "constant upgradability".
new features are fine, but they should be usable without breaking previos versions.
e.g., (defsystem .. :initially-do) should produce a warning that some arguments were ignored
and not a total failure.

basically, if you want asdf to be distributed with implementations, this calls for stability.
if you want constant upgrades, there is no point in distributing asdf with implementations:
people will have to get the bleeding edge version anyway.

what symbols are you binding in let which can produce warnings/errors?
I am afraid that you are caught in the same "legacy support" trap which (in mk:defsystem) prompted Dan to write asdf in the first place.
I think asdf2 is the right moment to remove the cruft accumulated in 8 years.
You might even want to rename asdf to hjkl (or qwer or zxcv) for that :-)

I do not see asdf-devel on gmane.org, so, please, start the discussion there without waiting for me.

You'd think deleting ASDF is as simple as delete-package, eh? WRONG. Been there, done that. Here's how you delete ASDF without breaking everything:
  http://github.com/fare/xcvb/blob/a65b31556f9849dab4dac22d64a21c4d7483f595/no-asdf.lisp
And then, you lose all information about previously-loaded systems, and put into limbo any package that :use's :asdf, which in turn could cause "interesting" problems.

Stability is achieved precisely through adaptability. It is necessary for each implementation to provide one version of ASDF, and that's all. ASDF is only converging faster because it is more tested, and it is more tested because people feel free to upgrade. We do sometimes make mistakes that break compatibility, and once again, upgradability ensures that this is fixed quick for everyone who cares, even when such a mistake makes it to an implementation. Without upgradability, we'd still be developing at the glacial pace of last year, and your many relevant RFEs would be pretty useless.

I started the discussion on asdf-devel already.
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
http://common-lisp.net/pipermail/asdf-devel/2010-August/001566.html

On 8/19/10, Faré <email address hidden> wrote:
> I started the discussion on asdf-devel already.
> http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
> http://common-lisp.net/pipermail/asdf-devel/2010-August/001566.html

thanks.
since the list is still not available on gmane.org, I am replying here.

the summary of my position is:

1. The footprint of asdf (3 pakages) is ridiculous. one package per
facility is perfectly enough for all other - much larger! - projects,
e.g., gsll, it should be eough for asdf.

2. Either asdf is stable and forward compatible (and then the users
are never expected to fetch their own versions and can always rely on
whatever the implementation ships) or asdf needs to be hot-swappable
(i.e., the users are supposed to run 'git pull' all the time and use
the latest and greatest asdf). Not both.

--
Sam Steingold <http://sds.podval.org>

1- While I agree that 3 packages is more than strictly necessary, I don't think packages are such a scarce resource as to require extra hacking. I will accept a patch provided that (a) it preserves backward compatibility (i.e. the author is willing to help with anyone who complains that he started to use the new package), (b) it preserves upgradability.

2- asdf is reasonably stable and forward compatible, and most users should rely on what the implementation provides. Still, bugs happen. Bug fixes happen. New features happen. *Sometimes* (hopefully, rarely), users will want to grab a more recent release (or use the thing from git).

Fixed in 2.122.

Released in 2.006.

Note that this is an API change, but it is compatible with ASDF 1 (that had a package asdf-extensions but failed to export anything from it), and I feel it's not too late to be incompatible with 2.000 to 2.005 on such an issue.