Upgrading/Installation Instructions Clarification

[Robert Goldman]

On 18 Jan 2021, at 17:37, Wilfredo Velazquez wrote:

> Hello all,
>
> Moving this question from
> https://gitlab.common-lisp.net/asdf/asdf/-/issues/52
>
> To reiterate, I believe that the instructions in
> https://common-lisp.net/project/asdf/asdf/Upgrading-ASDF.html 
> 'Upgrading
> ASDF' could use some clarification.
>
> I am attempting to run a newer version of ASDF than that provided by 
> my
> impl. The text I'm having issue with is:
>
>> If your implementation already provides ASDF 3 or later (and it 
>> should),
>> but you want a more recent ASDF version than your implementation 
>> provides,
>> then you just need to ensure the more recent ASDF is installed in a
>> configured path, like any other system. We recommend you download an
>> official tarball or checkout a release from git into 
>> ~/common-lisp/asdf/.
>> Once the source code for ASDF is installed, you don’t need any 
>> extra step
>> to load it beyond the usual (require "asdf"): ASDF 3 will 
>> automatically
>> look whether an updated version of itself is available amongst the
>> regularly configured systems, before it compiles anything else.

> First, it says I should download an official tarball. I looked to the 
> best
> of my ability and could not find one. Even if I had found one, I don't 
> know
> what I'd do with it.

There should be tarballs here:

https://common-lisp.net/project/asdf/

Look for the "Getting it" section.

> So I moved to the second option and cloned ASDF to 
> `~/common-lisp/asdf/`
> and built it successfully.
>
> I verify that indeed I am running a newer ASDF. However, I noticed
> `~/comon-lisp/asdf/ext/` includes certain third-party libraries 
> bundled in
> the repo. These are being prioritized over Quicklisp libraries, and 
> it's
> causing conflicts.
>
> So my question is:
>
> May I get clarification on how I may build & install ASDF such that 
> the
> implementation-bundled one will automatically find the newer version, 
> while
> omitting the libraries ext/ directory from being picked up?

As far as I can tell, if you put a directory tree into `~/common-lisp/`, 
ASDF will traverse it looking for system definitions, and there is 
nothing you can do to override this.  I have come to dislike the 
`~/common-lisp/` solution for this reason.

There are other ways you can make the new directory visible to ASDF 
*without* exposing `ext/`:

* The libraries in `ext/` are there so that ASDF can be downloaded in 
isolation and tested without any external dependencies.  If you don't 
pull the git submodules for the ASDF repository, they won't be there, 
and you won't have the problem you are having.  You could do "git get 
rid of my submodules" somehow, but this is the ASDF list, not the git 
help list -- you'll have to figure that out on your own!

* You can make the directory find-able using Faré's configuration 
language either directly in your lisp init file, or by using the 
environment variables.  I'm not a fan of environment variables, because 
they add more complexity to my lisp configuration.  I like to keep all 
of the configuration in my lisp init file, so I don't have to worry 
about *where* a setting is made.  If you add `(:directory <my asdf 
directory>)` to the configuration, then ASDF will not search it 
recursively (the alternative is the `:tree` keyword, which tells ASDF 
you *do* want it to search recursively). There's a way of making this 
same distinction in the environment variables: it's explained in the 
manual.

* If you are old school and don't want to fuss with debugging the 
configuration DSL, you can just do: `(push <my asdf directory> 
asdf:*central-registry*)` -- again, ASDF will not search this directory 
recursively.

I hope that will solve your problem!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20210118/7536eb78/attachment.html>