Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • A asdf
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 62
    • Issues 62
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 20
    • Merge requests 20
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • asdf
  • asdf
  • Issues
  • #84
Closed
Open
Issue created Jul 26, 2021 by Eric Timmons@etimmonsOwner

Upcoming trouble in next QL release

I briefly mentioned this in #83 (closed), but I think this is important enough to warrant a completely new issue, if for no other reason than to have a place to point users when they start having problems.

Xach discovered a few weeks ago that building systems with the UIOP 3.3.5 release would break occasionally. We tracked it down to an interaction between using Quicklisp with an older ASDF (like the one bundled with SBCL), the fasl cache, systems that use uiop:define-package but do not declare a dependency on uiop, and the package local nicknames support.

Basically, assume two systems similar to:

(defsystem "a"
 :components ((:file "a")))

(defsystem "b"
 :depends-on ("uiop" "a"))

And file a.lisp has:

(uiop:define-package #:a)

Assume SBCL with the standard fasl cache settings and built-in ASDF (so <3.3.5).

If you (ql:quickload :b), then in a new process (ql:quickload :a), you'll probably get an unknown-keyword-argument error.

What happens is that quickload'ing B may cause UIOP 3.3.5 to be loaded before a is loaded. If that happens, a's uiop:define-package will expand into a call to uiop:ensure-package with the keyword argument :local-nicknames present. Then, when you (ql:quickload :a) in the new process, a.fasl seems to still be valid and nothing causes UIOP 3.3.5 to be loaded. Therefore, loading a.fasl calls the older version of uiop:ensure-package which does not have the :local-nicknames argument.

There are multiple places this could be fixed, but I think ASDF is the best positioned to do it. We could release 3.3.6 (ideally before the next QL release) with a patch to uiop:define-package that only includes :local-nicknames in the expansion if it is non-NIL. That should keep code that doesn't explicitly ask for package local nicknames happy. For the systems that do ask for local nicknames, there's nothing we can do other than tell them to explicitly depend on UIOP, preferably using (:version "uiop" "3.3.5").

Other places this could be fixed include getting all implementations to bundle the latest ASDF (cons: never going to happen and won't help people running older releases of their implementation); get QL to distribute ASDF 3.3.5 (cons: not going to happen until all implementations bundle at least 3.3.5); get QL to hold off including UIOP 3.3.5 (cons: people are really excited about package local nicknames and is not a permanent solution); get QL to not distribute a newer UIOP than the ASDF it distributes (cons: cat's already out of the bag on this one); or get all systems that use uiop:define-package to put an explicit dependency on UIOP in their system definition (cons: this will take a lot of effort).

IRC log of us discovering this at https://irclog.tymoon.eu/libera/%23commonlisp?around=1625706408#1625706408

Edited Jul 26, 2021 by Eric Timmons
Assignee
Assign to
Time tracking