so, let's say i have an already initialized source registry, and from my .sbclrc i want to add one more directory to it.
currently this is what i kludged together, but it stinks:
(asdf:initialize-source-registry (append '(:source-registry) (butlast asdf:*source-registry-parameter*) `((:directory ,(merge-pathnames "whatever" (user-homedir-pathname)))) '(:inherit-configuration)))
or am i completely backwards with the cart, and i should just forget .sbclrc and use ~/.config/common-lisp/source-registry.conf.d/ for this?
the reason i prefer calling initialize-source-registry because then we can commit the right form into our env repo and the team members can have the exact same environment with less effort (just loading one repo-tracked file from .sbclrc).
Attila Lendvai wrote:
so, let's say i have an already initialized source registry, and from my .sbclrc i want to add one more directory to it.
currently this is what i kludged together, but it stinks:
(asdf:initialize-source-registry (append '(:source-registry) (butlast asdf:*source-registry-parameter*) `((:directory ,(merge-pathnames "whatever" (user-homedir-pathname)))) '(:inherit-configuration)))
or am i completely backwards with the cart, and i should just forget .sbclrc and use ~/.config/common-lisp/source-registry.conf.d/ for this?
the reason i prefer calling initialize-source-registry because then we can commit the right form into our env repo and the team members can have the exact same environment with less effort (just loading one repo-tracked file from .sbclrc).
Sorry, why is it that you put in the line with *source-registry-parameter* instead of simply adding the new directory?
BTW, for exactly your use case -- making it easy for people to put configurations in a revision control system, and have an entire team get their configuration that way, we added :HERE to the DSL for initializing the source registry.
[I feel compelled to disclose that because we have so much legacy code in that form, I still use the variable asdf:*central-registry* for my own configuration purposes, with an in-house library that essentially duplicates the function of Faré's directory traversal.]
Faré, why is it that *source-registry-parameter* is exported? It seems like a cache, and I don't understand why the user would need access to it.
Best, r
Sorry, why is it that you put in the line with *source-registry-parameter* instead of simply adding the new directory?
reading your answer makes me think i was unclear, sorry!
my situation is that i have a piece of code that collects directories and then initializes the registry by calling i-s-r.
and then i have another piece of code later on where i would like to add one more directory to the registry.
i couldn't find any other way to do that than the kludge in my previous mail.
BTW, for exactly your use case -- making it easy for people to put configurations in a revision control system, and have an entire team get their configuration that way, we added :HERE to the DSL for initializing the source registry.
thanks for the note! it will probably come handy when i get to port my registry initialization to the new way.
but first i wanted to get an impression whether i want/should/need to do that. with your mail i'm leaning more towards a yes now, which renders the original question somewhat moot.
[I feel compelled to disclose that because we have so much legacy code in that form, I still use the variable asdf:*central-registry* for my own configuration purposes, with an in-house library that essentially duplicates the function of Faré's directory traversal.]
same here... :)
On Mon, Feb 17, 2014 at 9:47 AM, Robert P. Goldman rpgoldman@sift.info wrote:
Attila Lendvai wrote:
so, let's say i have an already initialized source registry, and from my .sbclrc i want to add one more directory to it.
currently this is what i kludged together, but it stinks:
(asdf:initialize-source-registry (append '(:source-registry) (butlast asdf:*source-registry-parameter*) `((:directory ,(merge-pathnames "whatever" (user-homedir-pathname)))) '(:inherit-configuration)))
1- You seem to be repeating the :source-registry from the parameter (when not null), which cannot be good. Also, unless you specifically set it previously (which you probably did), the parameter needs not have :inherit-configuration (or its negation) last, and might be a string rather than a list.
2- In this context, you can use (:home "whatever") instead of this merge-pathnames form. You should get out of the habit of using merge-pathnames, the straightforward use of which is not portable to non-Unix pathnames (i.e. Windows, logical or URL pathnames). THOU SHALT NOT USE MERGE-PATHNAMES is a good style guide. Use instead UIOP:SUBPATHNAME, UIOP:MERGE-PATHNAMES*, UIOP:SUBPATHNAME*, etc.
or am i completely backwards with the cart, and i should just forget .sbclrc and use ~/.config/common-lisp/source-registry.conf.d/ for this?
That's an option: you could provide a file to copy and/or link into the source-registry.conf.d, and that would work for all implementations, not just SBCL.
the reason i prefer calling initialize-source-registry because then we can commit the right form into our env repo and the team members can have the exact same environment with less effort (just loading one repo-tracked file from .sbclrc).
For personal development, I'd recommend the file in source-registry.conf.d, and for deployment, I'd recommend a script that sets the CL_SOURCE_REGISTRY and/or has its own controlled parameter to initialize-source-registry.
Sorry, why is it that you put in the line with *source-registry-parameter* instead of simply adding the new directory?
BTW, for exactly your use case -- making it easy for people to put configurations in a revision control system, and have an entire team get their configuration that way, we added :HERE to the DSL for initializing the source registry.
Yes: if you symlink to a file that has a :here in it, *and* you didn't setf *resolve-symlinks* to nil, then pathnames in it will be relative to the true directory.
[I feel compelled to disclose that because we have so much legacy code in that form, I still use the variable asdf:*central-registry* for my own configuration purposes, with an in-house library that essentially duplicates the function of Faré's directory traversal.]
I still use the *central-directory* in many small tests, though I much prefer the *source-registry* for a well-managed source code.
Faré, why is it that *source-registry-parameter* is exported? It seems like a cache, and I don't understand why the user would need access to it.
You must be confusing *source-registry* and *source-registry-parameter*. The former is the cache after searching the various paths, and is private. The latter is the parameter provided to initialize-source-registry, and is exported specifically so that users may introspect what a another part of the program previous provided, and incrementally modify it. That's a feature that was requested by several users before I implemented it and exported the variable.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Austrian economics is the second law of thermodynamics to every other economist's perpetual motion machines. — Faré
Faré wrote:
Faré, why is it that *source-registry-parameter* is exported? It seems
like a cache, and I don't understand why the user would need access to it.
You must be confusing *source-registry* and *source-registry-parameter*. The former is the cache after searching the various paths, and is private. The latter is the parameter provided to initialize-source-registry, and is exported specifically so that users may introspect what a another part of the program previous provided, and incrementally modify it. That's a feature that was requested by several users before I implemented it and exported the variable.
Is this written up somewhere (e.g., launchpad)?*
If you can point me to such a description, I will add it to the manual. Currently, there's no docstring, nor is the variable mentioned in the manual.
Thanks! r
* Alas, it seems with the new mailing list service at cl.net, we can only retrieve messages from the archive with a precise designator. I have no idea how to search the archive now. :-(
You must be confusing *source-registry* and *source-registry-parameter*. The former is the cache after searching the various paths, and is private. The latter is the parameter provided to initialize-source-registry, and is exported specifically so that users may introspect what a another part of the program previous provided, and incrementally modify it. That's a feature that was requested by several users before I implemented it and exported the variable.
Is this written up somewhere (e.g., launchpad)?*
Not that I know.
If you can point me to such a description, I will add it to the manual.
The previous message is as close as you'll get to a description, I fear.
Currently, there's no docstring, nor is the variable mentioned in the manual.
That's a bug :-( Sorry.
- Alas, it seems with the new mailing list service at cl.net, we can
only retrieve messages from the archive with a precise designator. I have no idea how to search the archive now. :-(
If you search asdf-devel on google, you'll find that gmane and other mirror services have searchable archives.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "A society that puts equality — in the sense of equality of outcome — ahead of freedom will end up with neither equality nor freedom. The use of force to achieve equality will destroy freedom, and the force, introduced for good purposes, will end up in the hands of people who use it to promote their own interests." — Milton Friedman
Faré wrote:
You must be confusing *source-registry* and *source-registry-parameter*. The former is the cache after searching the various paths, and is private. The latter is the parameter provided to initialize-source-registry, and is exported specifically so that users may introspect what a another part of the program previous provided, and incrementally modify it.
Sorry, what I meant was that s-r-p is a cache of the previously-provided parameter to initialize-source-registry.
OK, that will be our documentation. I believe that this variable should be read only (hence my characterization of it as a cache).
cheers, r
On Mon, Feb 17, 2014 at 12:07 PM, Robert P. Goldman rpgoldman@sift.info wrote:
Faré wrote:
You must be confusing *source-registry* and *source-registry-parameter*. The former is the cache after searching the various paths, and is private. The latter is the parameter provided to initialize-source-registry, and is exported specifically so that users may introspect what a another part of the program previous provided, and incrementally modify it.
Sorry, what I meant was that s-r-p is a cache of the previously-provided parameter to initialize-source-registry.
OK, that will be our documentation. I believe that this variable should be read only (hence my characterization of it as a cache).
Well, the only useful way to write it is by calling initialize-source-registry; direct changes to it via setf will not have any effect beside confusing whoever will read it next (including i-s-r itself if called without a parameter).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Demand the establishment of the government in its rightful home at Disneyland.
-
Attila Lendvai -
Faré -
Robert P. Goldman