[asdf-devel] Best place to put a new config file?
If I'd like to extend the source registry by writing a registry configuration file somewhere, what's the best place to write that file? Is there a way to query the running system to get the answer? Is that necessary or is there some directory that is always good to use? Zach
On Thu, Nov 3, 2011 at 21:04, Zach Beane <xach@xach.com> wrote:
If I'd like to extend the source registry by writing a registry configuration file somewhere, what's the best place to write that file? Is there a way to query the running system to get the answer? Is that necessary or is there some directory that is always good to use?
Unhappily, it's a bit more complicated than it ought to be, at least unless you upgrade to the latest ASDF 2.018.6. My bad. Assuming ASDF 2.018.6, you may just put your files in either (asdf:merge-pathnames* asdf::*source-registry-directory* (first (asdf::user-configuration-directories))) or if you want something system-wide, (asdf:merge-pathnames* asdf::*source-registry-directory* (first (asdf::system-configuration-directories))) Note that you may have to (ensure-directories-exist ...) it into existence. With an older ASDF, doing the right thing on both Unix and Windows is quite complex, and basically requires reimplementing these functions from ASDF 2.018.6 - including the helper subpathname if you're using an ASDF older than 2.0.17.27. However, if you're only concerned about Unix, I don't believe that anyone on earth configured it to not be: ~/.config/common-lisp/source-registry.cond.d/ and if anyone did, whoever it is, they are probably on their own. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Individualism is thus an attitude of humility before this social process and of tolerance to other opinions, and is the exact opposite of that intellectual hubris which is at the root of the demand for comprehensive direction of the social process. — Friedrich August Hayek, The Road to Serfdom
Faré <fahree@gmail.com> writes:
On Thu, Nov 3, 2011 at 21:04, Zach Beane <xach@xach.com> wrote:
If I'd like to extend the source registry by writing a registry configuration file somewhere, what's the best place to write that file? Is there a way to query the running system to get the answer? Is that necessary or is there some directory that is always good to use?
Unhappily, it's a bit more complicated than it ought to be, at least unless you upgrade to the latest ASDF 2.018.6. My bad.
Assuming ASDF 2.018.6, you may just put your files in either (asdf:merge-pathnames* asdf::*source-registry-directory* (first (asdf::user-configuration-directories))) or if you want something system-wide, (asdf:merge-pathnames* asdf::*source-registry-directory* (first (asdf::system-configuration-directories))) Note that you may have to (ensure-directories-exist ...) it into existence.
Is this functionality likely to be available via exported symbols in the future?
With an older ASDF, doing the right thing on both Unix and Windows is quite complex, and basically requires reimplementing these functions from ASDF 2.018.6 - including the helper subpathname if you're using an ASDF older than 2.0.17.27.
However, if you're only concerned about Unix, I don't believe that anyone on earth configured it to not be: ~/.config/common-lisp/source-registry.cond.d/ and if anyone did, whoever it is, they are probably on their own.
What was the intended way to extend the registry? Externally via some editor after reading the manual section for your operating system? Zach
Unhappily, it's a bit more complicated than it ought to be, at least unless you upgrade to the latest ASDF 2.018.6. My bad.
Assuming ASDF 2.018.6, you may just put your files in either (asdf:merge-pathnames* asdf::*source-registry-directory* (first (asdf::user-configuration-directories))) or if you want something system-wide, (asdf:merge-pathnames* asdf::*source-registry-directory* (first (asdf::system-configuration-directories))) Note that you may have to (ensure-directories-exist ...) it into existence.
Is this functionality likely to be available via exported symbols in the future?
Tell me what API you want, I'll give you one. There was already an (unexported) API of sorts for read-only operations: user-output-translations-pathname () system-output-translations-pathname () user-output-translations-directory-pathname () system-output-translations-directory-pathname () These functions looked for the first configuration file or directory in the list that actually existed. What about having these functions take a keyword argument :direction which when it is :output, returns the first thing in the list that you may create? Or something like that. I suppose you'd want these functions exported, too.
However, if you're only concerned about Unix, I don't believe that anyone on earth configured it to not be: ~/.config/common-lisp/source-registry.cond.d/ and if anyone did, whoever it is, they are probably on their own.
What was the intended way to extend the registry? Externally via some editor after reading the manual section for your operating system?
Either programmatically from CL using some API to be agreed upon, or with the editor after reading the asdf manual, indeed. Or hopefully, after a discussion on this very mailing-list. I've tried to not implement ASDF features unless they was explicit demand for them. Admittedly, the barrier to demanding feature has historically been much lower within ITA, or within my own brain. Still, the point is, I have avoided creating and exposing APIs that do not have actual clients. (Rant: One of my strong goals as ASDF maintainer has been to keep it minimal. Though the size of ASDF has grown 2.5 times since I took it over, there is no piece that I would remove now, except those explicitly marked as obsolete and preserved for backwards compatibility. I'm sad every time I have to increase the line count of ASDF and rejoice every time I can reduce it, but judging from the code I previously had to maintain *outside* ASDF to achieve similar effects, I believe I decreased the overall line count of said software by moving some functionality into ASDF itself, and made things more portable to boot.) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org People are not born rich and become poor because of some dreadful phenomenon. They are born deprived of anything and become rich when they do but by the accumulated fruits of their own and their ancestors' labor: their capital.
: Xach : Faré
Is this functionality likely to be available via exported symbols in the future?
Tell me what API you want, I'll give you one. There was already an (unexported) API of sorts for read-only operations:
user-output-translations-pathname () system-output-translations-pathname () user-output-translations-directory-pathname () system-output-translations-directory-pathname ()
These functions looked for the first configuration file or directory in the list that actually existed.
What about having these functions take a keyword argument :direction which when it is :output, returns the first thing in the list that you may create? Or something like that.
I suppose you'd want these functions exported, too.
OK, I implemented this API in 2.018.7. If it suits you, I'll update the documentation. Otherwise, please tell me what you would like it to look like. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org History is about learning what was once topical news. Knowing what is topical news currently, you can only be struck with horror at the thought of learning thousands years worth of it...
On 11/4/11 Nov 4 -6:12 PM, Faré wrote:
: Xach : Faré
Is this functionality likely to be available via exported symbols in the future?
Tell me what API you want, I'll give you one. There was already an (unexported) API of sorts for read-only operations:
user-output-translations-pathname () system-output-translations-pathname () user-output-translations-directory-pathname () system-output-translations-directory-pathname ()
These functions looked for the first configuration file or directory in the list that actually existed.
What about having these functions take a keyword argument :direction which when it is :output, returns the first thing in the list that you may create? Or something like that.
I suppose you'd want these functions exported, too.
OK, I implemented this API in 2.018.7. If it suits you, I'll update the documentation. Otherwise, please tell me what you would like it to look like.
Is this compatible with an ASDF user who is using the old-school ASDF:*CENTRAL-REGISTRY* way of configuring ASDF instead of the new DSL? If not, is there some way for someone using this API to infer whether the current use is along the lines of ASDF:*CENTRAL-REGISTRY* or the DSL? r
OK, I implemented this API in 2.018.7. If it suits you, I'll update the documentation. Otherwise, please tell me what you would like it to look like.
Is this compatible with an ASDF user who is using the old-school ASDF:*CENTRAL-REGISTRY* way of configuring ASDF instead of the new DSL?
If not, is there some way for someone using this API to infer whether the current use is along the lines of ASDF:*CENTRAL-REGISTRY* or the DSL?
There is no plan to stop supporting the "old-school" asdf:*central-registry*. When used, it always takes precedence over the "new-fangled" source-registry. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A man is usually more careful of his money than he is of his principles. — Edgar Watson Howe
participants (3)
-
Faré -
Robert Goldman -
Zach Beane