search

quicklisp / quicklisp-client

Quicklisp client.
http://www.quicklisp.org/
MIT License
298 stars 75 forks source link

Dist system-index not initialized when accessing release systems #173

Closed mtstickney closed 6 years ago

mtstickney commented 6 years ago

I'm tracking down an issue I ran into when loading systems via qlot. After much debugging, I think I've found an issue in quicklisp that causes it.

qlot is doing the following when installing a dist (paraphrased a bit):

(ql-dist:install-dist "the-dist")
(dolist (release (ql-dist:provided-releases (ql-dist:dist "the-dist")))
  (ql-dist:ensure-installed release))

When install-dist is called, the slot-unbound method on the dist's provided-systems slot causes initialize-system-index to be called, which correctly picks up systems. However when installing a release in the second step, the slot-unbound method for the release's provided-systems slot only references the dist's system-index slot, not provided-systems. The slot-unbound method for system-index only creates a default hash-table, and does not initialize the system index; the release install winds up bombing out because find-system-in-dist has returned nil for a bunch of the dist's systems.

In this case, qlot could be modified to save the dist returned by install-dist instead of re-creating it from the distinfo file, but this seems an issue on the quicklisp side of things too. The most obvious would be to have the slot-unbound method for the system-index slot on dists do the initialization, so you always get an initialized index, but that causes an infinite loop (initialize-system-index retrieves system-index to check for items initialized via CDB).

Does this sound like a genuine issue in quicklisp, and if so, any ideas for a fix? I'll keep playing with it, and if I come with anything compelling I'll submit a PR.

mtstickney commented 6 years ago

I've been doing more testing, and it looks like I was mistaken the first time around -- what I observed was caused by the (to-be-fixed) assumption that system file names match system names in the slot-unbound method for a release's provided-systems slot, and an incorrect hack to blacklist some of wookie's plugin systems on my part.

As far as I can tell, quicklisp correctly adds new systems to the index when find-system-in-dist is called, provided that the system names match. Apologies for the false-positive report.