subject:"RE\: \[asdf\-devel\] Alternate default lisp system location"

: dherring
: sionescu
: rpgoldman
: sionescu

 For essential infrastructure like what ASDF claims to be, I expect major
 changes to happen less than once every 5 to 10 years.

Daniel, if you want changes only every 5 to 10 years, do like
janderson: try an upgrade every 5 years, find that it breaks your code
somehow and downgrade back to the old version without further
investigation. Then maybe 10 years from now you'll get the system
dependency bug fixed.

 You can expect whatever you want, but unless somebody is paid full-time
 to work on ASDF, it's not going to happen.

 Agreed.  Tell me: am I to piss our contributors off by refusing to
 accept their patches, in order to make happy the people who contribute
 only complaints? New features may simply be the price users pay to have
 bugs getting fixed.

 The force vs force-not message is a good example. A feature was added
 at the request of a user without considering all the use cases and now
 we discover that it's poorly thought out. When you say this has always
 been my impression..., it means that nobody ever even wrote down a
 rationale for that new feature so you don't *know*, you have
 impressions.

force and force-not were done well. The interaction between the two
was not well thought out, but obviously no one relied on the
interaction before force-not was implemented, so that was backward
compatible, and the recent change keeps the previously useful uses
working, so it is arguably, too.

It's not like my changes were done in secret. I did it and explained
what I did, and even mentioned at the time I didn't understand which
setting should take precedence over the other. I only apologize for
not understanding then the objection by Robert, though he also didn't
care enough to submit a patch, and no one else even complained.

  The more backwards compatibility, the better.  Projects like glibc
  have developed significant infrastructure to enable transparent
  improvements (see the ABI compliance checker, DSO symbol versioning,
  etc.).
 
  See above. That kind of backwards-compatibility is very difficult and
  burdensome.

 We spend a great deal of time maintaining backwards compatibility.
 Consider how much work was spent making the bug-fix coming from
 PREPARE-OP from breaking previous OPERATION subclasses.  Similarly, as
 someone who still uses ASDF:*CENTRAL-REGISTRY*, maintaining that is
 substantial backwards compatibility.

 The backwards-compatibility is not complete, though. When we're talking
 about glibc, we're talking about versioning functions and keeping the
 old entry points bug-to-bug compatible for ever while the new version of
 that function is simply an addition.
 Issuing a warning that OPERATION is being directly subclassed is not
 backwards-compatibility.

We do care about backward compatibility, a lot. Yes, there are
sometimes bugs in our backward-compatibility support. And then we
painfully fix them, as in the case of OPERATION above. Are we perfect?
No. Do we have symbol versioning for backwarder compatibility? No. The
libc has additional issues and solutions because it's all about binary
compatibility. We do not offer binary compatibility. We offer source
compatibility. We consider binary compatibility is backward.

  Every breaking change inflicts cost on a fraction of the existing
  userbase, in exchange for some proposed benefit to future users.  Every
  time I have to debug breakage and change something or redesign my workflow
  to maintain existing capability, it encourages me to explore other, more
  stable or better designed options...
 
  Sometimes good ideas fade after a month or two of reflection.  Some
  survive the test because the benefit truly outweighs the cost.  When that
  is the case, it is often helps to give the community time to prepare and
  minimize the number of times the community must change.  So propose the
  change, allow a long RFC window, allow users to obtain test
  implementations (while still promoting the stable branch), wait a while
  for several changes to collect before pushing them into major new
  releases, etc.
 
  I agree that an RFC-like process would be useful, instead of jumping in
  and implementing new features, as long as it's not too lengthy.
 

 It has, in fact, been a long time since ASDF's last release, October
 2013.  During that time, there have been a very large number of tagged
 versions available to the community.

 I don't think that this community can afford the time, nor can it muster
 the interest, to deal with such an RFC process.

 What community ?

If someone wants a RFC process, he's welcome to write a specification
for ASDF that all the currently documented or undocumented features
implicitly relied upon by every piece of software in Quicklisp, and
develop an independent reimplementation of ASDF based on that
specification.

Now I'll be the one laughing, and even more so if the RFC gets to also
specify all the backward compatibility features of ASDF.

For a

Re: [asdf-devel] Alternate default lisp system location

2014-03-13 Thread Robert P. Goldman

Daniel Herring wrote:
 In systems like OS-X-style disk images and Java-style jarfiles, the
 entire application is self-contained.  Thus it is quite appropriate for
 the full path to be user-visible, for deleting the file is uninstalling
 the app.

FWIW, Faré's new bundle operations begin to give support for this kind
of thing.

I still don't feel that ASDF is a *user* tool at all; only a programmer
tool.  Except to the extent that a programmer is a user of libraries.

Best,
r

Re: [asdf-devel] Alternate default lisp system location

2014-03-13 Thread Stelian Ionescu

On Thu, 2014-03-13 at 13:42 -0400, Faré wrote:
[...]
 force and force-not were done well. The interaction between the two
 was not well thought out, but obviously no one relied on the
 interaction before force-not was implemented, so that was backward
 compatible, and the recent change keeps the previously useful uses
 working, so it is arguably, too.
 
 It's not like my changes were done in secret.

They weren't done in secret, but many of them were just commits with no
discussion on the list.


[...]
 Every release comes with release notes that mention changes to the API.
 I haven't announced changes with every commit, because that would be verbose,
 and people who're interested can already read the git log.

Where are the release notes ? asdf-3.0.3.tar.gz(a tar bomb) contains no
such thing, nor the git repository.


-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.



signature.asc
Description: This is a digitally signed message part

Re: [asdf-devel] Alternate default lisp system location

2014-03-13 Thread Mark Evenson

I smell a need for a CDR, c'nest pas?

Tersely pecked on my iPad

On Mar 13, 2014, at 18:42, Faré fah...@gmail.com wrote:

 : dherring
 : sionescu
 : rpgoldman
 : sionescu
 
 For essential infrastructure like what ASDF claims to be, I expect major
 changes to happen less than once every 5 to 10 years.
 Daniel, if you want changes only every 5 to 10 years, do like
 janderson: try an upgrade every 5 years, find that it breaks your code
 somehow and downgrade back to the old version without further
 investigation. Then maybe 10 years from now you'll get the system
 dependency bug fixed.
 
 You can expect whatever you want, but unless somebody is paid full-time
 to work on ASDF, it's not going to happen.
 
 Agreed.  Tell me: am I to piss our contributors off by refusing to
 accept their patches, in order to make happy the people who contribute
 only complaints? New features may simply be the price users pay to have
 bugs getting fixed.
 
 The force vs force-not message is a good example. A feature was added
 at the request of a user without considering all the use cases and now
 we discover that it's poorly thought out. When you say this has always
 been my impression..., it means that nobody ever even wrote down a
 rationale for that new feature so you don't *know*, you have
 impressions.
 force and force-not were done well. The interaction between the two
 was not well thought out, but obviously no one relied on the
 interaction before force-not was implemented, so that was backward
 compatible, and the recent change keeps the previously useful uses
 working, so it is arguably, too.
 
 It's not like my changes were done in secret. I did it and explained
 what I did, and even mentioned at the time I didn't understand which
 setting should take precedence over the other. I only apologize for
 not understanding then the objection by Robert, though he also didn't
 care enough to submit a patch, and no one else even complained.
 
 The more backwards compatibility, the better.  Projects like glibc
 have developed significant infrastructure to enable transparent
 improvements (see the ABI compliance checker, DSO symbol versioning,
 etc.).
 
 See above. That kind of backwards-compatibility is very difficult and
 burdensome.
 
 We spend a great deal of time maintaining backwards compatibility.
 Consider how much work was spent making the bug-fix coming from
 PREPARE-OP from breaking previous OPERATION subclasses.  Similarly, as
 someone who still uses ASDF:*CENTRAL-REGISTRY*, maintaining that is
 substantial backwards compatibility.
 
 The backwards-compatibility is not complete, though. When we're talking
 about glibc, we're talking about versioning functions and keeping the
 old entry points bug-to-bug compatible for ever while the new version of
 that function is simply an addition.
 Issuing a warning that OPERATION is being directly subclassed is not
 backwards-compatibility.
 We do care about backward compatibility, a lot. Yes, there are
 sometimes bugs in our backward-compatibility support. And then we
 painfully fix them, as in the case of OPERATION above. Are we perfect?
 No. Do we have symbol versioning for backwarder compatibility? No. The
 libc has additional issues and solutions because it's all about binary
 compatibility. We do not offer binary compatibility. We offer source
 compatibility. We consider binary compatibility is backward.
 
 Every breaking change inflicts cost on a fraction of the existing
 userbase, in exchange for some proposed benefit to future users.  Every
 time I have to debug breakage and change something or redesign my workflow
 to maintain existing capability, it encourages me to explore other, more
 stable or better designed options...
 
 Sometimes good ideas fade after a month or two of reflection.  Some
 survive the test because the benefit truly outweighs the cost.  When that
 is the case, it is often helps to give the community time to prepare and
 minimize the number of times the community must change.  So propose the
 change, allow a long RFC window, allow users to obtain test
 implementations (while still promoting the stable branch), wait a while
 for several changes to collect before pushing them into major new
 releases, etc.
 
 I agree that an RFC-like process would be useful, instead of jumping in
 and implementing new features, as long as it's not too lengthy.
 
 It has, in fact, been a long time since ASDF's last release, October
 2013.  During that time, there have been a very large number of tagged
 versions available to the community.
 
 I don't think that this community can afford the time, nor can it muster
 the interest, to deal with such an RFC process.
 
 What community ?
 If someone wants a RFC process, he's welcome to write a specification
 for ASDF that all the currently documented or undocumented features
 implicitly relied upon by every piece of software in Quicklisp, and
 develop an independent reimplementation of ASDF based on that
 specification.

Re: [asdf-devel] Alternate default lisp system location

 Where are the release notes ? asdf-3.0.3.tar.gz(a tar bomb) contains no
 such thing, nor the git repository.

The debian/changelog doubles as release notes. I just updated the
README to point at them.

Release notes are otherwise posted to this mailing-list as part of
each release's announcement.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Demand the establishment of the government in its rightful home at Disneyland.

Re: [asdf-devel] Alternate default lisp system location

 It's not like my changes were done in secret.

 They weren't done in secret, but many of them were just commits with no
 discussion on the list.

As long as the change hasn't been released, it's up for discussion.
And it's much easier to discuss code that was committed than ideas in
the air. When I've committed changes I thought might be controversial,
I've always discussed them on the list, and indeed have backed out
many of them before release (or sometimes, after release, because
complaints only came afterwards).

I did my best to anticipate issues, but I often fail, and I can't read
minds. Complaints that come a year later are a year late.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Fascists divide in two categories: the fascists and the anti-fascists
— Ennio Flaiano

Re: [asdf-devel] Alternate default lisp system location

2014-03-13 Thread Stelian Ionescu

On Thu, 2014-03-13 at 14:52 -0400, Faré wrote:
  It's not like my changes were done in secret.
 
  They weren't done in secret, but many of them were just commits with no
  discussion on the list.
 
 As long as the change hasn't been released, it's up for discussion.

Do you seriously expect people to review the commit stream for
potentially harmful changes/addition ?

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.



signature.asc
Description: This is a digitally signed message part

Re: [asdf-devel] Alternate default lisp system location

 They weren't done in secret, but many of them were just commits with no
 discussion on the list.

 As long as the change hasn't been released, it's up for discussion.

 Do you seriously expect people to review the commit stream for
 potentially harmful changes/addition ?

Can you name a controversial ASDF feature that was not discussed on
the list before release?

What exactly do you wish had been debated before that wasn't?

And yes, at some point, I expect people to start a discussion if
something bugs them,
instead of waiting for the maintainer to start the discussion.

NB1: I'm not counting unannounced bug fixes and refactorings of internals.

NB2: I'm not counting UIOP either, that I've indeed developed without
much discussion,
except for my attempting some namespace landgrabs and retreating at
the backlash.
But that I haven't seen anyone else try to discuss it much,
apart from reporting a few bugs (for which I'm most grateful).

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Nobody seems more obsessed by diet than our antimaterialist, otherworldly,
New Age, spiritual types. But if the material world is merely illusion, an
honest guru should be as content with Budweiser and bratwurst as with raw
carrot juice, tofu, and seaweed slime. — Edward Abbey

Re: [asdf-devel] Alternate default lisp system location

: Faré
: janderson

 Daniel, if you want changes only every 5 to 10 years, do like
 janderson: try an upgrade every 5 years, find that it breaks your code
 somehow and downgrade back to the old version without further
 investigation. Then maybe 10 years from now you'll get the system
 dependency bug fixed.

 if one wishes to ascribe expectations to my actions, allow me to correct the
 presumption, as more accurate would be the hope, in ten years to have the
 luxury to work with a build system which leaves my dependency descriptions
 alone and uses them to do what it should, without failing for unrelated
 reasons.

Well, after 5 to 10 years, some amount of bitrot is to be expected,
especially for software that wasn't abandoned but saw active
development.

It is very unfair of you to complain without ever submitting a bug report:
we get no chance to defend ourselves. Did we do something stupid? Did you?
Was the issue a known backward incompatibility? Was there a trivial fix,
whether already documented or not yet? We'll never know.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
You can of course keep using any old ASDF 1 you like, or whichever or
even MK-DEFSYSTEM, which is quite stable. Only if you ever want to use
recent libraries that depend on new ASDF features or bug fixes, will
you have to upgrade your ASDF.

Re: [asdf-devel] Alternate default lisp system location

This has the potential of messing up already existing configurations (again!). 
The choice of ~/lisp would certainly mess up mine, and I can imagine many other 
scenarios. Please don't do that.

Thanks,
Pascal

Sent from my iPad

 On 12 Mar 2014, at 04:44, Robert P. Goldman rpgold...@sift.info wrote:
 
 Faré wrote:
 On Thu, Feb 27, 2014 at 11:30 PM, Robert P. Goldman rpgold...@sift.info 
 wrote:
 How would you all feel about an alternate default location for lisp
 systems, in addition to
 
 ~/.local/share/common-lisp/source/
 NB: I think a new additional location under ~/ for CL code would be great,
 and just *before* 3.1.1 is released would be the perfect time for it, since
 users can then rely on #-asdf3.1 for their backward compatibility recipes.
 
 I personally used ~/cl/ but think ~/common-lisp/ would be great too,
 and while I think ~/lisp/ is a bit misleading I would accept it as
 well. I really dislike ~/asdf-systems/ since other tools (e.g. XCVB)
 may want to use the same path, too.
 
 I'm ok with either ~/common-lisp/ or *both* ~/common-lisp/ *and* ~/cl/,
 whatever is the sense of the community.
 
 Let's make up our minds quickly, though, and make the change.
 
 I agree that 3.1.1 is a good time, and I would like to get the change
 into the manual now, too.
 
 Best,
 r

Re: [asdf-devel] Alternate default lisp system location

On Wed, Mar 12, 2014 at 2:49 AM, Pascal Costanza p...@p-cos.net wrote:
 This has the potential of messing up already existing configurations 
 (again!). The choice of ~/lisp would certainly mess up mine, and I can 
 imagine many other scenarios. Please don't do that.

I'm not sure what you mean by messing up your configuration.

How would it mess your configuration?

Do you have plenty of conflicting .asd's there that are going to
shadow those you like and each other?

Or are you expecting many seconds of scanning through deep directory
structures that may or may not contain .asd files?

Because adding them to the list is otherwise a NOP if the directories
don't exist or don't contain .asd files.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
He who says he will die for a cause will probably lie for it and may kill
for it.  — John McCarthy

Re: [asdf-devel] Alternate default lisp system location

I'm expecting asdf to suddenly see asd files that it shouldn't. (In my 
configuration, only ~/lisp/develop/ contains active systems, the rest of 
~/lisp may contain inactive ones - for example, alternate versions of the 
same systems.)

Pascal

Sent from my iPad

 On 12 Mar 2014, at 08:04, Faré fah...@gmail.com wrote:
 
 On Wed, Mar 12, 2014 at 2:49 AM, Pascal Costanza p...@p-cos.net wrote:
 This has the potential of messing up already existing configurations 
 (again!). The choice of ~/lisp would certainly mess up mine, and I can 
 imagine many other scenarios. Please don't do that.
 I'm not sure what you mean by messing up your configuration.
 
 How would it mess your configuration?
 
 Do you have plenty of conflicting .asd's there that are going to
 shadow those you like and each other?
 
 Or are you expecting many seconds of scanning through deep directory
 structures that may or may not contain .asd files?
 
 Because adding them to the list is otherwise a NOP if the directories
 don't exist or don't contain .asd files.
 
 —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
 He who says he will die for a cause will probably lie for it and may kill
 for it.  — John McCarthy

Re: [asdf-devel] Alternate default lisp system location

On Wed, Mar 12, 2014 at 3:16 AM, Pascal Costanza p...@p-cos.net wrote:
 I'm expecting asdf to suddenly see asd files that it shouldn't. (In my 
 configuration, only ~/lisp/develop/ contains active systems, the rest of 
 ~/lisp may contain inactive ones - for example, alternate versions of the 
 same systems.)

That's a fair complaint. And whichever name(s) we choose (if any),
there is the potential for a similar complaint.

Of course, you can always :ignore-inherited-configuration, but then
you might have to reproduce some of it that you like, and that's
painful.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
I object to doing things that computers can do.
— Olin Shivers

Re: [asdf-devel] Alternate default lisp system location

Pascal Costanza wrote:
 I'm expecting asdf to suddenly see asd files that it shouldn't. (In my 
 configuration, only ~/lisp/develop/ contains active systems, the rest of 
 ~/lisp may contain inactive ones - for example, alternate versions of the 
 same systems.)

Can you clarify?

Do you tell ASDF to load from particular subdirectories of ~/lisp/, but
allow it to load from the default directory as well (instead of ignoring
the inherited directories)?

I do not use the DSL, being entrenched in use of
ASDF:*CENTRAL-REGISTRY*, so I am not familiar with many users' practice.
 I suppose if one uses the DSL, one is likely to not use
:IGNORE-INHERITED-CONFIGURATION...

This suggests, regrettably, that using obvious directory names, such as
~/common-lisp/ might not be a good idea.

So we are searching for a directory name to use that will:

a. Be visible to standard directory listers, both graphical and textual
b. Not introduce more confusion -- so no ~/quux/
c. Not already be in use by many, ideally any, users.

I suggest that this means we should use something that has asdf in its
name.  Such as

asdf-src
cl-asdf-src
cl-src-asdf

I am open for suggestions.

I just stumbled on this when editing the manual (I will try to push my
edits today): I was sort of cringing at the idea of telling users they
should just put their systems in

~/.local/share/common-lisp/source

which did not seem like something that anyone not wedded to XDG would
even consider

Suggestions welcome!  Pascal, I appreciate your engaging in this
discussion: your participation will lead to better decision making.

best,
r

Re: [asdf-devel] Alternate default lisp system location

Pascal Costanza wrote:
 This has the potential of messing up already existing configurations 
 (again!). The choice of ~/lisp would certainly mess up mine, and I can 
 imagine many other scenarios. Please don't do that.

[By this we mean by default searching ~/common-lisp/ and/or ~/cl/ for
source files when loading ASDF systems.]

Can you explain why this would mess up your existing configurations and
what you would prefer?

The problem with the current default location is that it's in a
directory that's hidden by default.  So 'ls' and graphical file browsers
would (in their default mode), hide the user's source code. [It is
possible that hiding configuration files is a Good Thing; I can't
imagine a world in which hiding my source code from me is a Good Thing.]

Since this is a *default*, this would not clash with any existing
configurations in which the user has configured system search locations
by hand.

Since this would be an *alternate* default, it should not clash with
existing configurations that use the current default location,
~/.local/share/common-lisp/source

This is the reasoning behind my proposal. If there is something I'm
missing or something I have wrong, I would certainly like to know now,
before any changes are made and released to the world.

Thank you,
Robert

Re: [asdf-devel] Alternate default lisp system location

2014-03-12 Thread Stelian Ionescu

On Thu, 2014-02-27 at 22:30 -0600, Robert P. Goldman wrote:
 How would you all feel about an alternate default location for lisp
 systems, in addition to
 
 ~/.local/share/common-lisp/source/
 
 I'm sure that .local was chosen out of the (in)finite wisdom of XDG, but
 it just seems odd to me to hide the lisp systems from the user, which we
 are doing by putting them in a location that requires ls -a.
 
 After all, these are systems, not configuration files.
 
 What about ~/asdf-systems which doesn't make the poor user play peekaboo?
 
 I came across this while editing the manual. I don't use this directory
 myself; maybe everyone loves it.  Or maybe no one uses the standard
 default, and I shouldn't care.

I would ask you not to add any more hard-coded directories to ASDF, and
remove the already existing ones. If what you want is making life easy
for newcomers, make an additional tool that initializes a work
environment with convenient values, but separate the configuration of
ASDF from the core.

The only reason why ~/.local/share/common-lisp/source/ hasn't caused
complaints is because nobody was already using it. In my case, ~/lisp
has large numbers of duplicate .asd files and other systems I don't want
to expose so a :tree recursion there would be very annoying. And please
don't tell me to :ignore-inherited-configuration, for what's the point
of the default configuration if so many people either don't use it or
have to explicitly ignore it ?

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.



signature.asc
Description: This is a digitally signed message part

Re: [asdf-devel] Alternate default lisp system location

Robert P. Goldman rpgold...@sift.info writes:

 Stelian Ionescu wrote:
 On Thu, 2014-02-27 at 22:30 -0600, Robert P. Goldman wrote:
 How would you all feel about an alternate default location for lisp
 systems, in addition to

 ~/.local/share/common-lisp/source/

 I'm sure that .local was chosen out of the (in)finite wisdom of XDG, but
 it just seems odd to me to hide the lisp systems from the user, which we
 are doing by putting them in a location that requires ls -a.

 After all, these are systems, not configuration files.

 What about ~/asdf-systems which doesn't make the poor user play peekaboo?

 I came across this while editing the manual. I don't use this directory
 myself; maybe everyone loves it.  Or maybe no one uses the standard
 default, and I shouldn't care.
 
 I would ask you not to add any more hard-coded directories to ASDF, and
 remove the already existing ones. If what you want is making life easy
 for newcomers, make an additional tool that initializes a work
 environment with convenient values, but separate the configuration of
 ASDF from the core.
 
 The only reason why ~/.local/share/common-lisp/source/ hasn't caused
 complaints is because nobody was already using it. In my case, ~/lisp
 has large numbers of duplicate .asd files and other systems I don't want
 to expose so a :tree recursion there would be very annoying. And please
 don't tell me to :ignore-inherited-configuration, for what's the point
 of the default configuration if so many people either don't use it or
 have to explicitly ignore it ?
 

 The problem with not adding hard-coded directories is that configuration
 is too demanding of a new user.  I have just overhauled the manual, and
 there is WAY too much to have to know in order to just get started.

 IMO, no one should have to learn a complex DSL, or how to structure a
 conf.d directory in order to write his or her first lisp system.
 Compare with 'make' -- since make doesn't have to find its systems, it's
 trivial to build a makefile for your first C program.  That is not the
 case with ASDF -- you can write your first .asd file, but ASDF won't
 find it!

 Since ASDF *does* have to find the user's first ASDF file, we must make
 that trivial to do.

I think this could be simplified somewhat if it was easy to load or
register a system if you have its pathname. I've seen some people
recommend something like (load /path/to/project.asd), but I don't
think that establishes the same environment that asdf's find-system
mechanism does, so it could go wrong.

Is there some easy way, supported by ASDF, to make a system known to
ASDF if you have its pathname?

The complexity of the registry configuration is one reason why I added
the ~/quicklisp/local-projects/ mechanism.

Zach

Re: [asdf-devel] Alternate default lisp system location

2014-03-12 Thread Attila Lendvai

 to expose so a :tree recursion there would be very annoying. And please
 don't tell me to :ignore-inherited-configuration, for what's the point
 of the default configuration if so many people either don't use it or
 have to explicitly ignore it ?

well, for now it's two hard-core hackers, for whom it's probably
marginal to get things back on track *if* it actually breaks something
for them.

but we have no idea about the number of newcomers who fire up an
apt-get install sbcl for the first time in their lives, and just want
to try a piece of code copied from the net...

i still remember how goddamn high the fence was to first climb in to
the CL+emacs garden. i'm with Robert on this.

i'm not sure how the defaults would help on this, though. probably a
very slick quicklisp experience has more value than any of these
defaults can create.

just some 2¢,

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Be who you are and say what you feel, because those who mind don't
matter and those who matter don't mind.”
― Dr. Seuss (1904–1991)

Re: [asdf-devel] Alternate default lisp system location

Attila Lendvai wrote:
 to expose so a :tree recursion there would be very annoying. And please
 don't tell me to :ignore-inherited-configuration, for what's the point
 of the default configuration if so many people either don't use it or
 have to explicitly ignore it ?
 
 well, for now it's two hard-core hackers, for whom it's probably
 marginal to get things back on track *if* it actually breaks something
 for them.
 
 but we have no idea about the number of newcomers who fire up an
 apt-get install sbcl for the first time in their lives, and just want
 to try a piece of code copied from the net...
 
 i still remember how goddamn high the fence was to first climb in to
 the CL+emacs garden. i'm with Robert on this.
 
 i'm not sure how the defaults would help on this, though. probably a
 very slick quicklisp experience has more value than any of these
 defaults can create.

For the record, I agree with this.  I believe that installing quicklisp
is probably the best first step.  But see my earlier discussion about
Clojure.  I just want to start playing around in a repl, stashing some
code into files as I go.  Please make this as easy for me as possible,
and don't make me grok extra stuff.

I *will* ponder adding some introduction to Quicklisp to the ASDF
manual, though.  I think for lots of people that will be the easiest
path into CL, and there's no reason we should pretend not to know about
it in our documentation.

Cheers,
r

Re: [asdf-devel] Alternate default lisp system location

Robert Goldman rpgold...@sift.net writes:

 Zach Beane wrote:
 The complexity of the registry configuration is one reason why I added
 the ~/quicklisp/local-projects/ mechanism.

 Right, so I don't see why there's such a huge objection to having a
 similar mechanism for ASDF.  Stellian suggests using
 ~/quicklisp/local-projects/.  So why is it wrong for ASDF to have a
 local-projects directory?

 All I am suggesting is to have the local projects directory for ASDF be
 visible, instead of invisible.

 I stand corrected about using a name that the user might have already
 had (thanks, Pascal!) but I don't yet see a solution that's as easy as a
 default directory location.

I think having a similar mechanism would be good. (And the
loading-from-a-file thing could be nice too.)

I think the main problem is that giving it a nice name means that the
chance is high of it clashing with a nice name one or more users is
already using.

A while ago I was thinking it would be nice to have an API like this:

  register-system-directory directory key permanently 

Registers DIRECTORY as a directory to search for system files. If
PERMANENTLY is true, make the registration persist across sessions.

But then I got hung up about how to make PERMANENTLY work -- I don't
think there's any way to ask ASDF what directory is suitable for saving
a config file.

And I am 100% in favor of a nice solution that does not involve
Quicklisp. The simpler, the better.

Zach

Re: [asdf-devel] Alternate default lisp system location

2014-03-12 Thread Stelian Ionescu

On Wed, 2014-03-12 at 09:20 -0500, Robert P. Goldman wrote:
 Stelian Ionescu wrote:
  1) install Quicklisp, it's easy and painless
  2) put your projects in $QUICKLISPDIR/local-projects/
  
  done.
 
 I get you, but I don't like it.
 
 That's like saying I want to make my first C program. OK, let me
 teach you how to use apt-get.

Yes, and it's a very good idea to do just that because either you want
to use ASDF to load other libraries in which case you need QL, or a
simple file will suffice.


 Maybe this is the right answer, but it's not a path to getting a minimal
 understandable config for ASDF.  All that's happening here is that
 Quicklisp is hiding the complexity.

Which is very good. People that write .asd files aren't beginners.


 I am reminded of Clojure: I want to write my first Clojure program,
 what do I do?  First learn how Leiningen works.

Yes.
Want to learn node.js ? Use npm.
Want to learn ruby ? Use gems.
Want to learn python ? Use pip.
etc...

 I am happy for people to tell novices to start with Quicklisp, don't get
 me wrong.  And if that's their path into programming, instead of
 starting through ASDF, I'm fine with that, too.  But it doesn't remove
 the need for a trivial path into ASDF.

 Your email does suggest that ~/asdf-local-projects/ might be a suitable
 location...
 
 Similarly, it's unacceptable to have as the first instruction in our
 manual go off, find and install a script that configures our tool.
 That means that we have failed to provide an easily configurable tool.

What you want to provide is not an easily configurable tool, but an
already-configured tool.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.



signature.asc
Description: This is a digitally signed message part

Re: [asdf-devel] Alternate default lisp system location

2014-03-12 Thread Marco Antoniotti


On Mar 12, 2014, at 15:32 , Zach Beane x...@xach.com wrote:

 Robert Goldman rpgold...@sift.net writes:
 
 Zach Beane wrote:
 The complexity of the registry configuration is one reason why I added
 the ~/quicklisp/local-projects/ mechanism.
 
 Right, so I don't see why there's such a huge objection to having a
 similar mechanism for ASDF.  Stellian suggests using
 ~/quicklisp/local-projects/.  So why is it wrong for ASDF to have a
 local-projects directory?
 
 All I am suggesting is to have the local projects directory for ASDF be
 visible, instead of invisible.
 
 I stand corrected about using a name that the user might have already
 had (thanks, Pascal!) but I don't yet see a solution that's as easy as a
 default directory location.
 
 I think having a similar mechanism would be good. (And the
 loading-from-a-file thing could be nice too.)
 
 I think the main problem is that giving it a nice name means that the
 chance is high of it clashing with a nice name one or more users is
 already using.
 
 A while ago I was thinking it would be nice to have an API like this:
 
  register-system-directory directory key permanently 
 
Registers DIRECTORY as a directory to search for system files. If
PERMANENTLY is true, make the registration persist across sessions.

 But then I got hung up about how to make PERMANENTLY work -- I don't
 think there's any way to ask ASDF what directory is suitable for saving
 a config file.
 
 And I am 100% in favor of a nice solution that does not involve
 Quicklisp. The simpler, the better.

That is what MK:DEFSYSTEM used to (actually still does) have.

mk:add-registry-location pathname

I don’t think you want the ‘permanently’.  Your init file should be able to 
deal with that.

--
Marco Antoniotti

Re: [asdf-devel] Alternate default lisp system location

2014-03-12 Thread Attila Lendvai

 I think you will find that the configuration of the source search path
 is *very* complex, indeed too complex for a beginner.  It's great for
 hackers with complex requirements, but there's too much to be read if
 you just want to make one or two simple systems.

FTR, even i was mildly irritated by this when i first approached the
new ASDF config infrastructure.

but don't get me wrong, i have no ideas how to simplify it, and the
docs are probably also much better these days...

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
The essence of a civilized society: evidence trumps reason trumps emotions.

Re: [asdf-devel] Alternate default lisp system location

2014-03-12 Thread Stelian Ionescu

On Wed, 2014-03-12 at 10:04 -0500, Robert P. Goldman wrote:
 Stelian Ionescu wrote:
  It's very easy not to have a default directory at all.
 
 I'm sorry, I don't agree that this claim is correct.

You don't agree that it's always easier not to do anything ? Really ?


 I have just pushed my current draft of the ASDF manual, and I urge you
 to read it.

I've read it.


 I think you will find that the configuration of the source search path
 is *very* complex, indeed too complex for a beginner.

If it's complex, simplify it. You'd piling more stuff on top of the
current behaviour.


 It's great for hackers with complex requirements, but there's too much
 to be read if you just want to make one or two simple systems.

Nowadays, it's very rare to want to make one or two simple systems and
not need additional dependencies, in which case better use QL.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.



signature.asc
Description: This is a digitally signed message part

Re: [asdf-devel] Alternate default lisp system location

Stelian Ionescu wrote:
  I think you will find that the configuration of the source search path
  is *very* complex, indeed too complex for a beginner.
 
 If it's complex, simplify it. You'd piling more stuff on top of the
 current behaviour.
 
 

No, that is not the case.

I would be *simplifying* ~/.local/share/common-lisp/source to
~/asdf-local-projects/ and, perhaps most importantly, simplifying ls
-a ~/.local/share/common-lisp/source to ls ~/asdf-local-projects/

That's all I'm planning to do.

[Actually, to be fair, we would be complexifying a little, because we
would permit the users to continue to use
~/.local/share/common-lisp/source, in the unlikely event they are
already doing so.]

I take the point that using quicklisp might be the easiest thing to do,
but quicklisp is not my responsibility.  My job is to make ASDF usable.

I'm afraid I still don't understand why this makes you object so
strongly.  How does this concretely make your life, or someone else's
life more difficult?

I *do* get the objection that Pascal had, and I absolutely agree that we
should not choose a directory name that will collide with existing
users' directories.

Re: [asdf-devel] Alternate default lisp system location

On Wed, Mar 12, 2014 at 1:41 PM, Dave Cooper david.coo...@genworks.com wrote:

 On Wed, Mar 12, 2014 at 1:04 PM, Faré fah...@gmail.com wrote:



 1- I think we should proceed and add a default path anyway.
   ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
 complain about that.
   You could make it ~/local/common-lisp/ if you're into larger paths.



 How about providing the following as part of this:

 1. the option of a control file within that default path, to be able to
 specify subdirectories to be ignored. So anyone who already happens to have
 a ~/cl/ with a bunch of inactive subfolders with .asd files can make
 ~/cl/subdirs-to-exclude.asdc whose contents could be e.g.

   (inactive-proj-1 inactive-proj-2)

The source-registry :tree thing already provides for recursive exclusions.

I was thinking: since the :tree searcher already does a painful
recursive directory listing,
maybe it could recognize files named source-registry.conf or some
such, that explain
how things are laid out in this directory using :here.
Although, this makes the configuration language and search procedure
mutually recursive, which is dangerous.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Once a person has killed other people on behalf of an ideology, he becomes
rather devoted to it. — John McCarthy

Re: [asdf-devel] Alternate default lisp system location

2014-03-12 Thread Dave Cooper

 The source-registry :tree thing already provides for recursive exclusions.



Ok good. Then how about having ASDF loudly announce that it is registering
the default directory (e.g. ~/cl/), as well as providing the hint about
using a .conf file with the right syntax with :tree, if the user wants to
exclude certain subdirectories.

The goal here is to make the addition of the default registry directory as
painless and surprise-free as possible for anyone who already happens to
have stuff floating around in the new default directory.


-- 
My Best,

Dave Cooper

Re: [asdf-devel] Alternate default lisp system location

Dave Cooper david.coo...@genworks.com writes:

 The source-registry :tree thing already provides for recursive exclusions.



 Ok good. Then how about having ASDF loudly announce that it is registering
 the default directory (e.g. ~/cl/), as well as providing the hint about
 using a .conf file with the right syntax with :tree, if the user wants to
 exclude certain subdirectories.

 The goal here is to make the addition of the default registry directory as
 painless and surprise-free as possible for anyone who already happens to
 have stuff floating around in the new default directory.

I don't think I want to read loud announcements from ASDF. If it isn't
acting like I want, I'd rather read about how to make it do what I want
in a tutorial or manual.

Zach

Re: [asdf-devel] Alternate default lisp system location

2014-03-12 Thread Dave Cooper

On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane x...@xach.com wrote:

I don't think I want to read loud announcements from ASDF. If it isn't
 acting like I want, I'd rather read about how to make it do what I want
 in a tutorial or manual.



Loud announcement only in the initial ASDF release when the new default
directory is first introduced. In subsequent ASDF releases the announcement
would go away.

 Dave

Re: [asdf-devel] Alternate default lisp system location

Dave Cooper david.coo...@genworks.com writes:

 On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane x...@xach.com wrote:

 I don't think I want to read loud announcements from ASDF. If it isn't
 acting like I want, I'd rather read about how to make it do what I want
 in a tutorial or manual.



 Loud announcement only in the initial ASDF release when the new default
 directory is first introduced. In subsequent ASDF releases the announcement
 would go away.

I don't think it's a suitable way to communicate with me, even if it
only happens for a certain period of time.

Zach

Re: [asdf-devel] Alternate default lisp system location

Dave Cooper wrote:
 The goal here is to make the addition of the default registry directory
 as painless and surprise-free as possible for anyone who already happens
 to have stuff floating around in the new default directory. 

No, that would be the *subsidiary* goal.

The *primary* goal will be to make the probability of someone already
having stuff floating around in the new default directory as close to
zero as possible while still having a directory name that is easy to type!

Re: [asdf-devel] Alternate default lisp system location

Zach Beane wrote:
 Dave Cooper david.coo...@genworks.com writes:
 
 On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane x...@xach.com wrote:

 I don't think I want to read loud announcements from ASDF. If it isn't
 acting like I want, I'd rather read about how to make it do what I want
 in a tutorial or manual.


 Loud announcement only in the initial ASDF release when the new default
 directory is first introduced. In subsequent ASDF releases the announcement
 would go away.
 
 I don't think it's a suitable way to communicate with me, even if it
 only happens for a certain period of time.
 
 Zach
 

Agreed.  This is why we will choose a default directory name that will
not lead to such collisions.

Best,

r

Re: [asdf-devel] Alternate default lisp system location

Faré wrote:
 On Wed, Mar 12, 2014 at 1:41 PM, Dave Cooper david.coo...@genworks.com 
 wrote:
 On Wed, Mar 12, 2014 at 1:04 PM, Faré fah...@gmail.com wrote:


 1- I think we should proceed and add a default path anyway.
   ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
 complain about that.
   You could make it ~/local/common-lisp/ if you're into larger paths.

I think I will put asdf into the pathname, per our earlier discussion,
so that we don't step on pre-existing paths.

~/asdf-local-paths/

would work for me.

Squawks sooner rather than later, please.



 How about providing the following as part of this:

 1. the option of a control file within that default path, to be able to
 specify subdirectories to be ignored. So anyone who already happens to have
 a ~/cl/ with a bunch of inactive subfolders with .asd files can make
 ~/cl/subdirs-to-exclude.asdc whose contents could be e.g.

   (inactive-proj-1 inactive-proj-2)

 The source-registry :tree thing already provides for recursive exclusions.
 
 I was thinking: since the :tree searcher already does a painful
 recursive directory listing,
 maybe it could recognize files named source-registry.conf or some
 such, that explain
 how things are laid out in this directory using :here.
 Although, this makes the configuration language and search procedure
 mutually recursive, which is dangerous.

I'm reluctant to add this, versus trying to avoid name collisions, as an
extra complexity that will have to be explained in the manual.

Plus it will piss Pascal off! ;-)

Adding that complexity would also mean that we must further delay 3.1.1
release, and it's already pretty darn late.

I'm thinking that this will become 3.2, actually.  There are
sufficiently many improvements

Cheers,
r

RE: [asdf-devel] Alternate default lisp system location

2014-03-12 Thread Antoniotti Marco

Well. Quicklisp can change the unit files. Doesn't it?

I suppose it's the chicken and egg problem that is both ring you

Marco

Sent from my Windows Phone

From: Zach Beanemailto:x...@xach.com
Sent: ‎12/‎03/‎2014 17.33
To: Marco Antoniottimailto:marc...@cs.nyu.edu
Cc: ASDF-develmailto:asdf-devel@common-lisp.net
Subject: Re: [asdf-devel] Alternate default lisp system location

Marco Antoniotti marc...@cs.nyu.edu writes:

 On Mar 12, 2014, at 15:32 , Zach Beane x...@xach.com wrote:

 Robert Goldman rpgold...@sift.net writes:

 Zach Beane wrote:
 The complexity of the registry configuration is one reason why I added
 the ~/quicklisp/local-projects/ mechanism.

 Right, so I don't see why there's such a huge objection to having a
 similar mechanism for ASDF.  Stellian suggests using
 ~/quicklisp/local-projects/.  So why is it wrong for ASDF to have a
 local-projects directory?

 All I am suggesting is to have the local projects directory for ASDF be
 visible, instead of invisible.

 I stand corrected about using a name that the user might have already
 had (thanks, Pascal!) but I don't yet see a solution that's as easy as a
 default directory location.

 I think having a similar mechanism would be good. (And the
 loading-from-a-file thing could be nice too.)

 I think the main problem is that giving it a nice name means that the
 chance is high of it clashing with a nice name one or more users is
 already using.

 A while ago I was thinking it would be nice to have an API like this:

  register-system-directory directory key permanently

Registers DIRECTORY as a directory to search for system files. If
PERMANENTLY is true, make the registration persist across sessions.

 But then I got hung up about how to make PERMANENTLY work -- I don't
 think there's any way to ask ASDF what directory is suitable for saving
 a config file.

 And I am 100% in favor of a nice solution that does not involve
 Quicklisp. The simpler, the better.

 That is what MK:DEFSYSTEM used to (actually still does) have.

 mk:add-registry-location pathname

 I don’t think you want the ‘permanently’.  Your init file should be able to 
 deal with that.

I'd like to use this interface *instead* of thinking about which config
file to extend, and extend a cross-platform data file instead.

But I can't figure out how to do it, so it's a bit moot right now.

Zach

Re: [asdf-devel] Alternate default lisp system location

On Wed, Mar 12, 2014 at 2:25 PM, Zach Beane x...@xach.com wrote:
 Dave Cooper david.coo...@genworks.com writes:

 On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane x...@xach.com wrote:

 I don't think I want to read loud announcements from ASDF. If it isn't
 acting like I want, I'd rather read about how to make it do what I want
 in a tutorial or manual.

 Loud announcement only in the initial ASDF release when the new default
 directory is first introduced. In subsequent ASDF releases the announcement
 would go away.

 I don't think it's a suitable way to communicate with me, even if it
 only happens for a certain period of time.

I'm not sure what way of communicating you recommend, for changes in
default behavior of ASDF or recommended practice in using it.

Major changes like that happen less than once a year (ASDF 2 in 2010,
ASDF 3 in 2013, ASDF 3.1 soon in 2014), and while
backward-compatibility has always been a huge priority, improvements
sometimes do mean the recommended way of using ASDF changes, for the
better.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Clothes make the man.  Naked people have little or no influence on society.
— Mark Twain

Re: [asdf-devel] Alternate default lisp system location

 1- I think we should proceed and add a default path anyway.
   ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
 complain about that.
   You could make it ~/local/common-lisp/ if you're into larger paths.

 I think I will put asdf into the pathname, per our earlier discussion,
 so that we don't step on pre-existing paths.

 ~/asdf-local-paths/

 would work for me.

I really don't like including asdf in the name, especially since other
tools than asdf exist and may exist in the future, and will want to
share the common-lisp source code hierarchy.

~/local/common-lisp/ has the advantage of being clutter-limiting,
XDG-like if not strictly XDG, clean, etc., and just one character
longer than your proposal.

~/common-lisp/ is slightly more pretentious, but probably works, too.

~/cl/ is taking a lot of familiarity, and maybe I should keep it my
personal configuration rather than a recommended default.

 Squawks sooner rather than later, please.

Squawk, squawk!

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
*EULA: By reading or responding to this message you agree that all my stated
or unstated opinions are correct.* EULA — patent pending.

Re: [asdf-devel] Alternate default lisp system location

Faré wrote:
 1- I think we should proceed and add a default path anyway.
~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
  complain about that.
You could make it ~/local/common-lisp/ if you're into larger paths.
 
  I think I will put asdf into the pathname, per our earlier discussion,
  so that we don't step on pre-existing paths.
 
  ~/asdf-local-paths/
 
  would work for me.
 
 I really don't like including asdf in the name, especially since other
 tools than asdf exist and may exist in the future, and will want to
 share the common-lisp source code hierarchy.
 
 ~/local/common-lisp/ has the advantage of being clutter-limiting,
 XDG-like if not strictly XDG, clean, etc., and just one character
 longer than your proposal.

I am less excited about the future and find it more appealing in terms
of non-collision, to get asdf in the name.  But I am willing to be
overridden; my preference is weak.

OTOH, I don't like ~/local/common-lisp/ because it seems to me that the
local pathname component doesn't mean anything.  Its XDG-likeness
seems to me a hazard -- it can be confused with .local and has no
corresponding advantage.

Unless someone can convince me there's some useful tree to insert
ourselves into, I think the default lisp code directory should be a
direct subdirectory of ~, not an indirect one.

Does anyone have an argument for not being at the root?

 
 ~/common-lisp/ is slightly more pretentious, but probably works, too.
 
 ~/cl/ is taking a lot of familiarity, and maybe I should keep it my
 personal configuration rather than a recommended default.
 

These last two have been rejected by Pascal and others for what I feel
are good reasons.

Thanks, everyone!  I believe this discussion is leading us to a better
place

r

Re: [asdf-devel] Alternate default lisp system location

On Wed, Mar 12, 2014 at 3:17 PM, Robert P. Goldman rpgold...@sift.info wrote:
Faré wrote:
~/local/common-lisp/ has the advantage of being clutter-limiting,
XDG-like if not strictly XDG, clean, etc., and just one character
longer than your proposal.

I am less excited about the future and find it more appealing in terms
of non-collision, to get asdf in the name. But I am willing to be
overridden; my preference is weak.

The future you may hate your current self if you get asdf in that name.

OTOH, I don't like ~/local/common-lisp/ because it seems to me that the
local pathname component doesn't mean anything. Its XDG-likeness
seems to me a hazard -- it can be confused with .local and has no
corresponding advantage.

Fair enough. I admit I myself use a ~/local/ hierarchy that I manage with stow.
I used to do it with /usr/local, but it's hassle to compete with what
distributions and/or system administrators sometimes put there (on
shared or managed machines).

Unless someone can convince me there's some useful tree to insert
ourselves into, I think the default lisp code directory should be a
direct subdirectory of ~, not an indirect one.

I think you have a point.

Does anyone have an argument for not being at the root?

Avoid clutter, if many languages each do that.

~/common-lisp/ is slightly more pretentious, but probably works, too.

That would be my preference.

~/cl/ is taking a lot of familiarity, and maybe I should keep it my
personal configuration rather than a recommended default.

These last two have been rejected by Pascal and others for what I feel
are good reasons.

I thought Pascal has just rejected ~/lisp/ because of his current setup.
I haven't seen anyone comment on either ~/common-lisp/ or ~/cl/

I believe that ~/common-lisp/ is the Right Thing™ at this point.

Thanks, everyone! I believe this discussion is leading us to a better
place

Right before the 3.1 release is the perfect time for bikeshedding.
Afterwards, it will be too late to say you can depend on that
predicated on #+asdf3.1.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
One of the greatest discoveries a man makes, one of his great surprises,
is to find he can do what he was afraid he couldn't do. — Henry Ford

Re: [asdf-devel] Alternate default lisp system location

asdf is not a tool for beginners. Beginners will either deal with a bare Common 
Lisp implementation, or they want to experiment with third-party libraries, in 
which case they want to use quicklisp these days. Once you need to define your 
own systems, you're not a beginner anymore, and a good tutorial helps a lot 
more than any supporting wheels can. It's already hard enough to ensure that 
asdf doesn't accidentally find systems you don't want it to find, you shouldn't 
make it even harder.

On top of that, with the proposed scheme, you will create a situation where 
there are not only two default locations for user-defined systems, but three 
when quicklisp is active. I find it hard to imagine that beginners will find 
this easy to grasp.

Just my 0.02€...

Pascal

Sent from my iPad

 On 12 Mar 2014, at 16:04, Robert P. Goldman rpgold...@sift.info wrote:
 
 Stelian Ionescu wrote:
 It's very easy not to have a default directory at all.
 
 I'm sorry, I don't agree that this claim is correct.  I have just pushed
 my current draft of the ASDF manual, and I urge you to read it.
 
 I think you will find that the configuration of the source search path
 is *very* complex, indeed too complex for a beginner.  It's great for
 hackers with complex requirements, but there's too much to be read if
 you just want to make one or two simple systems.
 
 Please do skim at least the first few pages, and I think you will see
 what I mean.
 
 Best,
 r

Re: [asdf-devel] Alternate default lisp system location

Yuck...

Sent from my iPad

 On 12 Mar 2014, at 18:41, Dave Cooper david.coo...@genworks.com wrote:
 
 
 On Wed, Mar 12, 2014 at 1:04 PM, Faré fah...@gmail.com wrote:
 
  
 1- I think we should proceed and add a default path anyway.
   ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
 complain about that.
   You could make it ~/local/common-lisp/ if you're into larger paths.
 
 
 How about providing the following as part of this:
 
 1. the option of a control file within that default path, to be able to 
 specify subdirectories to be ignored. So anyone who already happens to have a 
 ~/cl/ with a bunch of inactive subfolders with .asd files can make 
 ~/cl/subdirs-to-exclude.asdc whose contents could be e.g.
 
   (inactive-proj-1 inactive-proj-2)
 
 2. When registering systems in the default location, loudly announce that 
 this is happening, e.g:
 
   *
 Automatically registering .asd systems under ~/cl/... 
 
Protip: if you want to exclude certain subdirectories, create file 
 
  ~/cl/subdirs-to-exclude.asdc
 
   containing a list of the subdirectory names to be excluded, e.g.
 
(inactive-proj-1 inactive-proj-2)
 
   *
 
 
 
 -- 
 My Best,
 
 Dave Cooper

Re: [asdf-devel] Alternate default lisp system location



 ~/common-lisp/ is slightly more pretentious, but probably works, too.
 That would be my preference.
 
 ~/cl/ is taking a lot of familiarity, and maybe I should keep it my
 personal configuration rather than a recommended default.
 
 These last two have been rejected by Pascal and others for what I feel
 are good reasons.
 I thought Pascal has just rejected ~/lisp/ because of his current setup.
 I haven't seen anyone comment on either ~/common-lisp/ or ~/cl/
 
 I believe that ~/common-lisp/ is the Right Thing™ at this point.

Are you saying that I just got lucky because I happen to be subscribed to this 
mailing list, but it's ok if other people have to suffer?

For the records, I don't like any of the suggested default paths.

Just make this a configuration option. For example, an environment variable, or 
so, then everybody can choose their own preferred name.

export ASDF_DEFAULT_PATH=~/common-lisp

...and please make this empty by default, so it doesn't mess up anything unless 
I ask it to do so...

Thanks,
Pascal

Re: [asdf-devel] Alternate default lisp system location

Pascal Costanza wrote:
 
 ~/common-lisp/ is slightly more pretentious, but probably works, too.
 That would be my preference.

 ~/cl/ is taking a lot of familiarity, and maybe I should keep it my
 personal configuration rather than a recommended default.
 These last two have been rejected by Pascal and others for what I feel
 are good reasons.
 I thought Pascal has just rejected ~/lisp/ because of his current setup.
 I haven't seen anyone comment on either ~/common-lisp/ or ~/cl/

 I believe that ~/common-lisp/ is the Right Thing™ at this point.
 
 Are you saying that I just got lucky because I happen to be subscribed to 
 this mailing list, but it's ok if other people have to suffer?

No, I am saying that you correctly pointed out that we should avoid a
pathname that people are likely already to be using.
 
 For the records, I don't like any of the suggested default paths.
 
 Just make this a configuration option. For example, an environment variable, 
 or so, then everybody can choose their own preferred name.
 
 export ASDF_DEFAULT_PATH=~/common-lisp
 
 ...and please make this empty by default, so it doesn't mess up anything 
 unless I ask it to do so...

I'm sorry, but that is not on the table.

We are looking for a solution that will work without any active
configuration by the user, beyond put your system definition here, and
you don't have to do anything.

Best,
r

Re: [asdf-devel] Alternate default lisp system location

On Wed, Mar 12, 2014 at 3:08 PM, Zach Beane x...@xach.com wrote:
Faré fah...@gmail.com writes:

On Wed, Mar 12, 2014 at 2:25 PM, Zach Beane x...@xach.com wrote:
Dave Cooper david.coo...@genworks.com writes:

On Wed, Mar 12, 2014 at 2:05 PM, Zach Beane x...@xach.com wrote:

I don't think I want to read loud announcements from ASDF. If it isn't
acting like I want, I'd rather read about how to make it do what I want
in a tutorial or manual.

Loud announcement only in the initial ASDF release when the new default
directory is first introduced. In subsequent ASDF releases the announcement
would go away.

I don't think it's a suitable way to communicate with me, even if it
only happens for a certain period of time.

I'm not sure what way of communicating you recommend, for changes in
default behavior of ASDF or recommended practice in using it.

I'd like to see the behavior clearly documented in the manual and
explained in a release announcement or blog post or tutorial or all of
the above.

I don't want the software to print extra things out during some
transition period.

Oh wait, you're right, I hadn't realized that Dave had proposed ASDF
printing a message at runtime.

Indeed, it's a bug for ASDF to announce anything at runtime, unless
verbosity is explicitly required and/or a warning or error happens.
The test suite actually includes a test-clean-load target that fails
if loading ASDF emits any information. A TODO item would be to also
test that using ASDF produces no output.

I thought the loud announcement under discussion was to happen in
the manual and release notes and while releasing the software — the
usual procedure, just louder than usual due to major changes (yet
still maintaining backward compatibility).

My apologies for the misunderstanding.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Every technique is first developed, then used, important, obsolete,
normalized, and finally understood.

Re: [asdf-devel] Alternate default lisp system location

: Faré
: p-cos
: rpgoldman

asdf is not a tool for beginners. Beginners will either deal with a bare
Common Lisp implementation, or they want to experiment with third-party
libraries, in which case they want to use quicklisp these days. Once you
need to define your own systems, you're not a beginner anymore, and a good
tutorial helps a lot more than any supporting wheels can. It's already hard
enough to ensure that asdf doesn't accidentally find systems you don't want
it to find, you shouldn't make it even harder.

ASDF is a tool for everyone, beginners and experts alike, at least
since ASDF2. The ability to just work out of the box yet be
configurable by program user system, was a strong requirement for
ASDF2, and I believe we have been by and large successful at it,
despite the complexity (only to be seen by experts).

Yes, you can define your own systems without having to learn all the
details of ASDF — or you should be able to. A better default location
for code than ~/.local/share/common-lisp/ makes total sense, and I am
100% behind Robert on that. I only apologize for not making it happen
as early as ASDF2.

I believe that ~/common-lisp/ is the Right Thing™ at this point.

Are you saying that I just got lucky because I happen to be subscribed to
this mailing list, but it's ok if other people have to suffer?

No, I am saying that you correctly pointed out that we should avoid a
pathname that people are likely already to be using.

On the other hand, anyone who already has his system configured in any
way will have ASDF find his systems where he already configured it,
and the defaults only apply for systems not already configured.

The only time a new default will cause a system you don't want to
shadow a system you want is if you rely on earlier, lower priority
defaults: if Pascal expects some system loaded from
/usr/share/common-lisp/source/ but has an outdated copy in ~/lisp/old/
then he's in trouble. Otherwise, not.

Note that some of the XDG default paths were broken from 2.27 to 3.0.2
included (see commit 285a61e before 3.0.2.9), so effective changes in
the defaults have happened in the past, and not anyone noticed except
a few unhappy Debian users (my apologies to them).

I still believe that ~/common-lisp/ is a much better choice than
~/asdf-local-projects/ or anything.

For the records, I don't like any of the suggested default paths.

You don't have to like them. You're a big boy, you can easily override
them. You can even use :ignore-inherited-configuration.

Just make this a configuration option. For example, an environment variable,
or so, then everybody can choose their own preferred name.

export ASDF_DEFAULT_PATH=~/common-lisp

You can already do that:
export CL_SOURCE_REGISTRY=~/common-lisp//

The question is about what defaults should be, for beginners.

...and please make this empty by default, so it doesn't mess up anything
unless I ask it to do so...

I'm sorry, but that is not on the table.

We are looking for a solution that will work without any active
configuration by the user, beyond put your system definition here, and
you don't have to do anything.

I totally agree with Robert.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?

Re: [asdf-devel] Alternate default lisp system location

Can I set CL_SOURCE_REGISTRY to a value that deactivates all default paths?
Then I don't care what the default is...

Pascal

Sent from my iPad

On 12 Mar 2014, at 22:14, Faré fah...@gmail.com wrote:

: Faré
: p-cos
: rpgoldman

On top of that, with the proposed scheme, you will create a situation where
there are not only two default locations for user-defined systems, but
three when quicklisp is active. I find it hard to imagine that beginners
will find this easy to grasp.
ASDF is a tool for everyone, beginners and experts alike, at least
since ASDF2. The ability to just work out of the box yet be
configurable by program user system, was a strong requirement for
ASDF2, and I believe we have been by and large successful at it,
despite the complexity (only to be seen by experts).

I believe that ~/common-lisp/ is the Right Thing™ at this point.

Are you saying that I just got lucky because I happen to be subscribed to
this mailing list, but it's ok if other people have to suffer?

No, I am saying that you correctly pointed out that we should avoid a
pathname that people are likely already to be using.
On the other hand, anyone who already has his system configured in any
way will have ASDF find his systems where he already configured it,
and the defaults only apply for systems not already configured.

I still believe that ~/common-lisp/ is a much better choice than
~/asdf-local-projects/ or anything.

For the records, I don't like any of the suggested default paths.
You don't have to like them. You're a big boy, you can easily override
them. You can even use :ignore-inherited-configuration.

Just make this a configuration option. For example, an environment
variable, or so, then everybody can choose their own preferred name.

export ASDF_DEFAULT_PATH=~/common-lisp
You can already do that:
export CL_SOURCE_REGISTRY=~/common-lisp//

The question is about what defaults should be, for beginners.

...and please make this empty by default, so it doesn't mess up anything
unless I ask it to do so...

I'm sorry, but that is not on the table.

We are looking for a solution that will work without any active
configuration by the user, beyond put your system definition here, and
you don't have to do anything.
I totally agree with Robert.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?

Re: [asdf-devel] Alternate default lisp system location

On Wed, Mar 12, 2014 at 6:07 PM, Pascal Costanza p...@p-cos.net wrote:
 Can I set CL_SOURCE_REGISTRY to a value that deactivates all default paths? 
 Then I don't care what the default is...

Yes, the example I gave you did that:

export CL_SOURCE_REGISTRY=~/lisp//

As you can see with (asdf::parse-source-registry-string
/home/tunes/lisp//), it expands to:
(:SOURCE-REGISTRY (:TREE /home/tunes/lisp)
 (:IGNORE-INHERITED-CONFIGURATION))

The double-slash // is significative: it means recurse through the directory.

Those readers who do want to inherit the configuration should just add
a colon : at the end
— or a semi-colon, if using Windows:
export CL_SOURCE_REGISTRY=~/lisp//:

Alternatively, you can put this in your
~/.config/common-lisp/source-registry.conf:
(:source-registry (:tree (:home lisp)) :ignore-inherited-configuration)

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Just because your semi-free country government is evil doesn't mean native
governments have a right to exist and enslave their people. — Faré

Re: [asdf-devel] Alternate default lisp system location

Sent from my iPad

 On 12 Mar 2014, at 23:39, Faré fah...@gmail.com wrote:
 
 On Wed, Mar 12, 2014 at 6:07 PM, Pascal Costanza p...@p-cos.net wrote:
 Can I set CL_SOURCE_REGISTRY to a value that deactivates all default 
 paths? Then I don't care what the default is...
 Yes, the example I gave you did that:
 
 export CL_SOURCE_REGISTRY=~/lisp//
 
 As you can see with (asdf::parse-source-registry-string
 /home/tunes/lisp//), it expands to:
 (:SOURCE-REGISTRY (:TREE /home/tunes/lisp)
 (:IGNORE-INHERITED-CONFIGURATION))
 
 The double-slash // is significative: it means recurse through the 
 directory.

Erm what? Do you or do you not recur with this syntax?

 Those readers who do want to inherit the configuration should just add
 a colon : at the end
 — or a semi-colon, if using Windows:
 export CL_SOURCE_REGISTRY=~/lisp//:

What does inheriting a configuration mean?

 Alternatively, you can put this in your
 ~/.config/common-lisp/source-registry.conf:
 (:source-registry (:tree (:home lisp)) :ignore-inherited-configuration)

I'm confused. Which of those options does what I want?

Why can't I just say something like this?

export CL_SOURCE_REGISTRY=

or something similar, which just leaves this setting empty?

Pascal

Re: [asdf-devel] Alternate default lisp system location

Faré fah...@gmail.com writes:

 On Wed, Mar 12, 2014 at 6:07 PM, Pascal Costanza p...@p-cos.net wrote:
 Can I set CL_SOURCE_REGISTRY to a value that deactivates all default 
 paths? Then I don't care what the default is...

 Yes, the example I gave you did that:

 export CL_SOURCE_REGISTRY=~/lisp//

 As you can see with (asdf::parse-source-registry-string
 /home/tunes/lisp//), it expands to:
 (:SOURCE-REGISTRY (:TREE /home/tunes/lisp)
  (:IGNORE-INHERITED-CONFIGURATION))

 The double-slash // is significative: it means recurse through the 
 directory.

 Those readers who do want to inherit the configuration should just add
 a colon : at the end
 — or a semi-colon, if using Windows:
 export CL_SOURCE_REGISTRY=~/lisp//:

 Alternatively, you can put this in your
 ~/.config/common-lisp/source-registry.conf:
 (:source-registry (:tree (:home lisp)) :ignore-inherited-configuration)

Instructions like these are one of the reasons I have been unable to
make or recommend regular use of the source registry configuration
system.

Zach

Re: [asdf-devel] Alternate default lisp system location

On Wed, Mar 12, 2014 at 7:24 PM, Zach Beane x...@xach.com wrote:
 Faré fah...@gmail.com writes:

 On Wed, Mar 12, 2014 at 6:07 PM, Pascal Costanza p...@p-cos.net wrote:
 Can I set CL_SOURCE_REGISTRY to a value that deactivates all default 
 paths? Then I don't care what the default is...

 Yes, the example I gave you did that:

 export CL_SOURCE_REGISTRY=~/lisp//

 As you can see with (asdf::parse-source-registry-string
 /home/tunes/lisp//), it expands to:
 (:SOURCE-REGISTRY (:TREE /home/tunes/lisp)
  (:IGNORE-INHERITED-CONFIGURATION))

 The double-slash // is significative: it means recurse through the 
 directory.

 Those readers who do want to inherit the configuration should just add
 a colon : at the end
 — or a semi-colon, if using Windows:
 export CL_SOURCE_REGISTRY=~/lisp//:

 Alternatively, you can put this in your
 ~/.config/common-lisp/source-registry.conf:
 (:source-registry (:tree (:home lisp)) :ignore-inherited-configuration)

 Instructions like these are one of the reasons I have been unable to
 make or recommend regular use of the source registry configuration
 system.

You could also
mkdir -p ~/.config/common-lisp/
echo \$HOME/lisp//\  ~/.config/common-lisp/source-registry.conf

I don't know what kind of instructions you want.

Having good defaults is precisely what makes such instructions
superfluous for beginners, and why Robert wants to define a better
default location for code than currently used.

Having instructions is still necessary for people who want to override
the defaults — and anyone who wants to release software built in a
controlled repeatable way needs understand how to do that.

If you have a better design to offer, I'm sure Robert is listening.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Verbal constructs of above-average phonemic quantity implement the qualitative
actualization of cognitive disenlightenment. (Big words obscure meaning.)

Re: [asdf-devel] Alternate default lisp system location


On Wed, 12 Mar 2014, Faré wrote:


1- I think we should proceed and add a default path anyway.
 ~/cl/ and/or ~/common-lisp/ sound fine to me, and I've seen no one
complain about that.
 You could make it ~/local/common-lisp/ if you're into larger paths.


The computer I'm currently on uses ~/lisp for a lot of non-ASDF-related 
systems, including numerous files that are not source code.  On some other 
systems, I use paths like ~/cl to distinguish from ~/racket and other 
dialects.


I agree with others who dislike this idea.  ASDF will inflict significant 
end-user pain for little benefit if it chooses to do a land grab on an 
obvious directory name.


In my opinion, a lot of the complexity in ASDF, and a lot the motivation 
for this proposal, stems from ASDF's conflation of the loader with the 
build system.  That's the topic for another post...


- Daniel

Re: [asdf-devel] Alternate default lisp system location


On Wed, 12 Mar 2014, Dave Cooper wrote:


Ok good. Then how about having ASDF loudly announce that it is registering the 
default directory (e.g. ~/cl/), as well as providing the hint about using a 
.conf file with the right syntax with :tree, if the user wants to exclude
certain subdirectories. 


Loud announcements are almost as bad as the problem.

If you have to shout at the user, then you are probably about to do 
something wrong...


I understand the problem people have with the XDG complexity, and the 
flaws of the old (but oh so simple) asdf:*central-registry*.  The current 
proposal strikes me as a hasty solution.


- Daniel

Re: [asdf-devel] Alternate default lisp system location


On Wed, 12 Mar 2014, Robert P. Goldman wrote:


~/asdf-local-paths/

would work for me.

Squawks sooner rather than later, please.


If we are decided on adding a default path, please make it consistent with 
the other XDG stuff in ASDF...


I'm not XDG guru, but here's a link to the standard...

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

It looks like default paths would belong under $XDG_DATA_HOME and 
$XDG_DATA_DIRS.


Looking at the current ASDF manual, it appears that there is already some 
support for this concept?


http://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-searches-for-systems


The source registry will be configured from a default configuration. This 
configuration may allow for implementation-specific systems to be found, 
for systems to be found the current directory (at the time that the 
configuration is initialized) as well as :directory entries for 
$XDG_DATA_DIRS/common-lisp/systems/ and :tree entries for 
$XDG_DATA_DIRS/common-lisp/source/. For instance, SBCL will include 
directories for its contribs when it can find them; it will look for them 
where SBCL was installed, or at the location specified by the SBCL_HOME 
environment variable




Later,
Daniel

Re: [asdf-devel] Alternate default lisp system location


On Wed, 12 Mar 2014, Faré wrote:


Major changes like that happen less than once a year (ASDF 2 in 2010,
ASDF 3 in 2013, ASDF 3.1 soon in 2014), and while
backward-compatibility has always been a huge priority, improvements
sometimes do mean the recommended way of using ASDF changes, for the
better.


For essential infrastructure like what ASDF claims to be, I expect major 
changes to happen less than once every 5 to 10 years.  The more backwards 
compatibility, the better.  Projects like glibc have developed significant 
infrastructure to enable transparent improvements (see the ABI compliance 
checker, DSO symbol versioning, etc.).


Every breaking change inflicts cost on a fraction of the existing 
userbase, in exchange for some proposed benefit to future users.  Every 
time I have to debug breakage and change something or redesign my workflow 
to maintain existing capability, it encourages me to explore other, more 
stable or better designed options...


Sometimes good ideas fade after a month or two of reflection.  Some 
survive the test because the benefit truly outweighs the cost.  When that 
is the case, it is often helps to give the community time to prepare and 
minimize the number of times the community must change.  So propose the 
change, allow a long RFC window, allow users to obtain test 
implementations (while still promoting the stable branch), wait a while 
for several changes to collect before pushing them into major new 
releases, etc.


- Daniel

Re: [asdf-devel] Alternate default lisp system location

I am sorry, but I promise you that this will NOT be consistent with XDG. I have 
no idea why those people think it's a good idea to put files in directories 
where ls cannot find them.

ASDF already has a deeply-nested, invisible-to-ls location that is XDG 
compliant where you can put your files if that's what floats your boat.

It was writing a description of where to put your files in this XDG-compliant 
location that convinced me that we needed an alternative that was obvious and 
easily accessible.

In case you haven't guessed, I'm not a fan of this standard! :-)

On March 12, 2014 10:10:20 PM CDT, Daniel Herring dherr...@tentpost.com wrote:
On Wed, 12 Mar 2014, Robert P. Goldman wrote:

 ~/asdf-local-paths/

 would work for me.

 Squawks sooner rather than later, please.

If we are decided on adding a default path, please make it consistent
with 
the other XDG stuff in ASDF...

I'm not XDG guru, but here's a link to the standard...

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

It looks like default paths would belong under $XDG_DATA_HOME and 
$XDG_DATA_DIRS.

Looking at the current ASDF manual, it appears that there is already
some 
support for this concept?

http://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-searches-for-systems


The source registry will be configured from a default configuration.
This 
configuration may allow for implementation-specific systems to be
found, 
for systems to be found the current directory (at the time that the 
configuration is initialized) as well as :directory entries for 
$XDG_DATA_DIRS/common-lisp/systems/ and :tree entries for 
$XDG_DATA_DIRS/common-lisp/source/. For instance, SBCL will include 
directories for its contribs when it can find them; it will look for
them 
where SBCL was installed, or at the location specified by the SBCL_HOME

environment variable



Later,
Daniel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [asdf-devel] Alternate default lisp system location

Seriously, my source code is not config data, so IMO the XDG standard has 
nothing to say about where it's placed. Unlike the case for config files.

If my source code is to be hidden from me in a config directory what, pray tell 
is my home directory for?

On March 12, 2014 10:10:20 PM CDT, Daniel Herring dherr...@tentpost.com wrote:
On Wed, 12 Mar 2014, Robert P. Goldman wrote:

 ~/asdf-local-paths/

 would work for me.

 Squawks sooner rather than later, please.

If we are decided on adding a default path, please make it consistent
with 
the other XDG stuff in ASDF...

I'm not XDG guru, but here's a link to the standard...

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

It looks like default paths would belong under $XDG_DATA_HOME and 
$XDG_DATA_DIRS.

Looking at the current ASDF manual, it appears that there is already
some 
support for this concept?

http://common-lisp.net/project/asdf/asdf.html#Controlling-where-ASDF-searches-for-systems


The source registry will be configured from a default configuration.
This 
configuration may allow for implementation-specific systems to be
found, 
for systems to be found the current directory (at the time that the 
configuration is initialized) as well as :directory entries for 
$XDG_DATA_DIRS/common-lisp/systems/ and :tree entries for 
$XDG_DATA_DIRS/common-lisp/source/. For instance, SBCL will include 
directories for its contribs when it can find them; it will look for
them 
where SBCL was installed, or at the location specified by the SBCL_HOME

environment variable



Later,
Daniel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [asdf-devel] Alternate default lisp system location


On Wed, 12 Mar 2014, Robert P. Goldman wrote:


I am sorry, but I promise you that this will NOT be consistent with XDG. I have 
no idea why those people think it's a good idea to put files in directories 
where ls cannot find them.

ASDF already has a deeply-nested, invisible-to-ls location that is XDG 
compliant where you can put your files if that's what floats your boat.

It was writing a description of where to put your files in this XDG-compliant 
location that convinced me that we needed an alternative that was obvious and 
easily accessible.

In case you haven't guessed, I'm not a fan of this standard! :-)


I would agree that XDG is over-engineered and under-specified.

However, ls finds dot files just fine (alias ls=ls -A if it helps), and 
normal users usually install programs in system directories, not their 
home directory.


Given the current CL ecosystem, things are constantly changing, 
implementations provide little fasl compatibility, CL installs are often 
per-user, etc.  Thus the current best default for sources is in $HOME.  I 
would argue that the use of $HOME is the real problem, and hiding things 
is the right solution for users (as opposed to developers who can be 
expected to memorize a slightly obscure path).


Two default paths is not better than one.

There is a reason MS Windows has hide system files enabled by default. 
Some things are too complicated for casual users, and an obscure 
~/common-lisp is just asking for grandma to delete the folder she 
doesn't want...


In systems like OS-X-style disk images and Java-style jarfiles, the 
entire application is self-contained.  Thus it is quite appropriate for 
the full path to be user-visible, for deleting the file is uninstalling 
the app.


- Daniel

P.S.  In case I've gone off-kilter, I promise to get some sleep before any 
further replies.

Re: [asdf-devel] Alternate default lisp system location

: rpgoldman
: dherring

I am sorry, but I promise you that this will NOT be consistent with XDG. I
have no idea why those people think it's a good idea to put files in
directories where ls cannot find them.

ASDF already has a deeply-nested, invisible-to-ls location that is XDG
compliant where you can put your files if that's what floats your boat.

Given the current CL ecosystem, things are constantly changing,
implementations provide little fasl compatibility, CL installs are often
per-user, etc. Thus the current best default for sources is in $HOME. I
would argue that the use of $HOME is the real problem, and hiding things
is the right solution for users (as opposed to developers who can be
expected to memorize a slightly obscure path).

Two default paths is not better than one.

There is a reason MS Windows has hide system files enabled by default.
Some things are too complicated for casual users, and an obscure
~/common-lisp is just asking for grandma to delete the folder she doesn't
want...

In systems like OS-X-style disk images and Java-style jarfiles, the entire
application is self-contained. Thus it is quite appropriate for the full
path to be user-visible, for deleting the file is uninstalling the app.

I believe that there are different kinds of users, and that
ASDF should provide sensible defaults for all of them.

On the one hand, there are hypothetical end-users of software written in CL.
For these users, who don't program, and don't want to see the Lisp source,
the XDG standard makes perfect sense, and we already support it.

On the other hand, there are also low-commitment programmers,
who may be beginners or occasional members of the community,
and who would like a simple no-configuration way of hacking code
without having to deal with magic invisible XDG paths.
For them, a ~/common-lisp/ is perfect;
it would also play the role of ~/quicklisp/local-projects or whatever.

Once again, if someone already has a ~/common-lisp/, it should not
matter too much,
since the default only applies after whatever they explicitly configured,
and only shadows other lower-priority defaults — and if it does affect them,
they can easily configure ASDF to skip this default.

A small pain for a handful of hypothetical current users,
a nice gain for all future users.

As for self-contained apps, you can already do that:
just have your start script (either Lisp code or shell wrapper)
properly configure the source-registry.
Actually, any release engineer worth his grain will make sure
his builds are self-contained and reproducible,
built from well-versioned compilers, etc.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Language is froth on the surface of thought. — John McCarthy

Re: [asdf-devel] Alternate default lisp system location