FAQ
CPAN prefers to use File::HomeDir to determine it own directory, so far that
has been `$HOME/.cpan`. F::H 0.90 adds XDG support, accordingly the directory
moved to a different location, except for the configuration file whose
location is sort of hard-coded if missing. cpan from App::Cpan allows the user
to name a configuration file, I had to tweak CPAN slightly to prefer
committing to that file if specified. I published the changes at
<http://github.com/daxim/cpanpm/commits>. (Pull request to andk coming soon.)
Together this made it possible for me to get rid of `$HOME/.cpan` altogether,
I keep CPAN's data now at standard-conformant locations in the file system.
alias cpan
alias cpan='$HOME/local/bin/cpan -s -j $HOME/.config/cpan/Config.pm'
ack HOME ~/.config/cpan/Config.pm
my $HOME = $ENV{HOME};
'build_dir' => qq[$HOME/.cache/cpan-build],
'cpan_home' => qq[$HOME/.local/share/cpan],
'histfile' => qq[$HOME/.local/share/cpan/histfile],
'keep_source_where' => qq[$HOME/.cache/cpan-sources],
'prefs_dir' => qq[$HOME/.local/share/cpan/prefs],
'urllist' => [ qq[file://$HOME/.cache/cpan-sources],

Search Discussions

  • David Golden at Feb 18, 2010 at 4:04 am

    On Wed, Feb 17, 2010 at 3:29 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote:
    CPAN prefers to use File::HomeDir to determine it own directory, so far that
    has been `$HOME/.cpan`. F::H 0.90 adds XDG support, accordingly the directory
    I suspect that's going to be a world of pain. Historically, it's been
    important during testing to be able to set $ENV{HOME} to a temp
    directory and see that config files and other things wind up there
    (because File::HomeDir::Unix->my_data was the same as my_home).

    If File::HomeDir no longer bases my_data on my_home on Unix systems,
    then anything that relies on my_data may start overwriting real user
    config data during testing if they have an upgraded File::HomeDir.

    I strongly suggest that File::HomeDir not default to FreeDesktop mode
    unless explicitly requested.

    Either way, it needs at least a major version bump and lots of public notice.

    -- David
  • Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 at Feb 18, 2010 at 2:12 pm
    I of course ran `perl Makefile.PL ; make ; make testdistro ; make test` on the
    source directory before committing and encountered no problems. Tests pass, my
    configuration below `$HOME/.config` was not overwritten, and also no
    `$HOME/.cpan` directory appeared again once I earlier had deleted it for good.
    So, »works on my machine«.

    Are you referring to the tests of the CPAN distro or something else?
  • David Golden at Feb 18, 2010 at 3:03 pm

    On Thu, Feb 18, 2010 at 9:12 AM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote:
    I of course ran `perl Makefile.PL ; make ; make testdistro ; make test` on the
    source directory before committing and encountered no problems. Tests pass, my
    configuration below `$HOME/.config` was not overwritten, and also no
    `$HOME/.cpan` directory appeared again once I earlier had deleted it for good.
    So, »works on my machine«.

    Are you referring to the tests of the CPAN distro or something else?
    Anything *else* on CPAN that does this:

    (a) uses File::HomeDir->my_data

    (b) Overrides $ENV{HOME} to a temp directory for testing creation of
    config files (instead of, say, mocking File::HomeDir->my_data)

    This presumes that they don't care or don't realize that $ENV{HOME}
    doesn't affect my_data on Windows.

    Adam's suggestion is only a so-so answer because users might
    legitimately have reasons to set HOME and XDG_DATA_HOME differently.

    The handful of modules I spot check seem to either just use my_home()
    directly instead of my_data() or if they use my_data(), they mock it
    or have some other override that avoids File::HomeDir entirely.

    Here's my revised suggestion: add something to the File::HomeDir
    module (or distribution) that is the "official" way to mock/override
    File::HomeDir for testing and then advertise the hell out of it. (And
    possibly email every author that uses File::HomeDir on CPAN)

    That could be any of these:

    (a) Some global variable that takes precedence over HOME, HOMEDIR,
    XDG_*, whatever

    (b) A File::HomeDir::Mock module that creates a temporary directory
    and points every other call to a subdirectory of it. E.g.

    /tmp/File-HomeDir-tmp498723487/
    my_home/
    my_data/
    my_documents/
    ...

    I think (b) is a safer bet. Ideally, tests would just need to load it
    early, and then it would ensure that all subsequent use of
    File::HomeDir in that process is safely segregated from real user
    data.

    -- David

    P.S. Alias++ for the pun
  • Adam Kennedy at Feb 18, 2010 at 3:59 pm
    (b) sounds like an interesting idea.

    Adam K
    On Fri, Feb 19, 2010 at 2:03 AM, David Golden wrote:
    On Thu, Feb 18, 2010 at 9:12 AM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote:
    I of course ran `perl Makefile.PL ; make ; make testdistro ; make test` on the
    source directory before committing and encountered no problems. Tests pass, my
    configuration below `$HOME/.config` was not overwritten, and also no
    `$HOME/.cpan` directory appeared again once I earlier had deleted it for good.
    So, »works on my machine«.

    Are you referring to the tests of the CPAN distro or something else?
    Anything *else* on CPAN that does this:

    (a) uses File::HomeDir->my_data

    (b) Overrides $ENV{HOME} to a temp directory for testing creation of
    config files (instead of, say, mocking File::HomeDir->my_data)

    This presumes that they don't care or don't realize that $ENV{HOME}
    doesn't affect my_data on Windows.

    Adam's suggestion is only a so-so answer because users might
    legitimately have reasons to set HOME and XDG_DATA_HOME differently.

    The handful of modules I spot check seem to either just use my_home()
    directly instead of my_data() or if they use my_data(), they mock it
    or have some other override that avoids File::HomeDir entirely.

    Here's my revised suggestion:  add something to the File::HomeDir
    module (or distribution) that is the "official" way to mock/override
    File::HomeDir for testing and then advertise the hell out of it.  (And
    possibly email every author that uses File::HomeDir on CPAN)

    That could be any of these:

    (a) Some global variable that takes precedence over HOME, HOMEDIR,
    XDG_*, whatever

    (b) A File::HomeDir::Mock module that creates a temporary directory
    and points every other call to a subdirectory of it.  E.g.

    /tmp/File-HomeDir-tmp498723487/
    my_home/
    my_data/
    my_documents/
    ...

    I think (b) is a safer bet.  Ideally, tests would just need to load it
    early, and then it would ensure that all subsequent use of
    File::HomeDir in that process is safely segregated from real user
    data.

    -- David

    P.S. Alias++ for the pun
  • Adam Kennedy at Feb 18, 2010 at 2:47 pm
    File::HomeDir is _supposed_ to support overloading of home directories
    via $ENV{HOME} at all times (even on Windows, where the HOME variable
    doesn't exist).

    We may need to add some special casing someone can demonstrate this
    not working, perhaps we can ask the XDG for the home directory, and if
    the result doesn't match $ENV{HOME} we ignore everything else that XDG
    says... (pun totally intended) :)

    Adam K
    On Thu, Feb 18, 2010 at 3:03 PM, David Golden wrote:
    On Wed, Feb 17, 2010 at 3:29 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote:
    CPAN prefers to use File::HomeDir to determine it own directory, so far that
    has been `$HOME/.cpan`. F::H 0.90 adds XDG support, accordingly the directory
    I suspect that's going to be a world of pain.  Historically, it's been
    important during testing to be able to set $ENV{HOME} to a temp
    directory and see that config files and other things wind up there
    (because File::HomeDir::Unix->my_data was the same as my_home).

    If File::HomeDir no longer bases my_data on my_home on Unix systems,
    then anything that relies on my_data may start overwriting real user
    config data during testing if they have an upgraded File::HomeDir.

    I strongly suggest that File::HomeDir not default to FreeDesktop mode
    unless explicitly requested.

    Either way, it needs at least a major version bump and lots of public notice.

    -- David
  • Brian d foy at Feb 23, 2010 at 7:59 pm
    [[ This message was both posted and mailed: see
    the "To," "Cc," and "Newsgroups" headers for details. ]]

    In article <201002172129.57556.daxim@cpan.org>, Lars DŠ�·¥á·¥Ñ·¥ã·¥è·¥°
    Ëø�ÊãâÊñØ wrote:
    I had to tweak CPAN slightly to prefer
    committing to that file if specified. I published the changes at
    <http://github.com/daxim/cpanpm/commits>.
    Can we do this without adding yet another global variable, and
    certainly not no in a completely different package that might not even
    be loaded when someone is using CPAN.pm.

    I like the idea, but that patch isn't going to make it into App::Cpan.
  • Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 at Apr 16, 2010 at 2:10 pm

    brian d foy ✍:
    Can we do this without adding yet another global variable, and
    certainly not no in a completely different package that might not even
    be loaded when someone is using CPAN.pm.
    You're right. This was the result of programming the solution that came to my
    mind first.

    It's much better when a environment variable is used instead. I have reworked
    the patches at <http://github.com/daxim/cpanpm/commits>, have a look.
  • Curtis Jewell at Apr 16, 2010 at 3:01 pm
    While you're at it, can you do this:

    If neither the $ENV{CPAN_CONFIG} or CPAN/Config.pm locations are
    writable, then write the configuration back to the logical
    CPAN/MyConfig.pm location when changed, rather than erroring out?
    On Fri, 16 Apr 2010 16:10 +0200, "Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯" wrote:
    brian d foy ✍:
    Can we do this without adding yet another global variable, and
    certainly not no in a completely different package that might not even
    be loaded when someone is using CPAN.pm.
    You're right. This was the result of programming the solution that came
    to my
    mind first.

    It's much better when a environment variable is used instead. I have
    reworked
    the patches at <http://github.com/daxim/cpanpm/commits>, have a look.
    --Curtis
    --
    Curtis Jewell
    swordsman@csjewell.fastmail.us

    %DCL-E-MEM-BAD, bad memory
    -VMS-F-PDGERS, pudding between the ears

    [I use PC-Alpine, which deliberately does not display colors and pictures in HTML mail]

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedFeb 17, '10 at 8:30p
activeApr 16, '10 at 3:01p
posts9
users5
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase