New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conformation to XDG Base Directory Specification #1407

Merged
merged 17 commits into from Jan 18, 2016

Conversation

Projects
None yet
@ntoniazzi
Contributor

ntoniazzi commented Dec 11, 2012

A minor change to conform to the "XDG Base Directory Specification" (http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html - https://developer.gnome.org/basedir-spec/).

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Dec 11, 2012

Member

I am ok with conforming with XDG_CONFIG_HOME if it's set, but following the spec to the point of putting stuff in ~/.config/.composer if the XDG env is not set is maybe going too far here.

The problem is that it changes the current expectations, which means suddenly when people update stuff that worked doesn't anymore, their config/cache will appear to be gone, and the documentation is also not updated.

Member

Seldaek commented Dec 11, 2012

I am ok with conforming with XDG_CONFIG_HOME if it's set, but following the spec to the point of putting stuff in ~/.config/.composer if the XDG env is not set is maybe going too far here.

The problem is that it changes the current expectations, which means suddenly when people update stuff that worked doesn't anymore, their config/cache will appear to be gone, and the documentation is also not updated.

@ntoniazzi

This comment has been minimized.

Show comment
Hide comment
@ntoniazzi

ntoniazzi Dec 11, 2012

Contributor

Yes, you are right. Forcing the use of .config is not a good idea. But XDG_CONFIG_HOME not being set doesn't mean that the system is not following the standard. It simply defaults to $HOME/.config. Checking for XDG_CONFIG_DIRS instead (which must be set) might be more accurate.

In the case there we need to use the XDG env, we can check for the presence of $HOME/.composer and move it to the new location. The cache and config will be preserved.

I'll update the doc, sorry about that.

Contributor

ntoniazzi commented Dec 11, 2012

Yes, you are right. Forcing the use of .config is not a good idea. But XDG_CONFIG_HOME not being set doesn't mean that the system is not following the standard. It simply defaults to $HOME/.config. Checking for XDG_CONFIG_DIRS instead (which must be set) might be more accurate.

In the case there we need to use the XDG env, we can check for the presence of $HOME/.composer and move it to the new location. The cache and config will be preserved.

I'll update the doc, sorry about that.

@ntoniazzi ntoniazzi closed this Dec 11, 2012

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Dec 12, 2012

Member

That sounds like a better solution indeed. I guess you closed the issue by mistake?

Member

Seldaek commented Dec 12, 2012

That sounds like a better solution indeed. I guess you closed the issue by mistake?

@Seldaek Seldaek reopened this Dec 12, 2012

@ntoniazzi

This comment has been minimized.

Show comment
Hide comment
@ntoniazzi

ntoniazzi Dec 12, 2012

Contributor

Yes, my finger slipped.

Contributor

ntoniazzi commented Dec 12, 2012

Yes, my finger slipped.

@psychoticmeow

This comment has been minimized.

Show comment
Hide comment
@psychoticmeow

psychoticmeow Jul 2, 2014

Is this work still being considered? I'd like to get this out of my home directory.

psychoticmeow commented Jul 2, 2014

Is this work still being considered? I'd like to get this out of my home directory.

@jrobeson

This comment has been minimized.

Show comment
Hide comment
@jrobeson

jrobeson Jul 13, 2014

Contributor

composer also stores backup phar files in ~/.composer/ (for rollback), so that doesn't mesh well with using ~/.config/composer.

So either the composer backup phar files need to be stored in ~/.cache/composer OR ~/.local/share/composer should be used instead.

Contributor

jrobeson commented Jul 13, 2014

composer also stores backup phar files in ~/.composer/ (for rollback), so that doesn't mesh well with using ~/.config/composer.

So either the composer backup phar files need to be stored in ~/.cache/composer OR ~/.local/share/composer should be used instead.

@jrobeson

This comment has been minimized.

Show comment
Hide comment
@jrobeson

jrobeson Oct 15, 2014

Contributor

ping @ntoniazzi ? check my last comment.

Contributor

jrobeson commented Oct 15, 2014

ping @ntoniazzi ? check my last comment.

@alcohol

This comment has been minimized.

Show comment
Hide comment
@alcohol

alcohol Dec 12, 2014

Member

In its current state this PR changes the default home directory to $HOME/composer (note the missing .) on *nix systems that don't have any XDG environment variables set. This is neither the current directory nor a XDG defaults suggestion. Is that intended?

Member

alcohol commented Dec 12, 2014

In its current state this PR changes the default home directory to $HOME/composer (note the missing .) on *nix systems that don't have any XDG environment variables set. This is neither the current directory nor a XDG defaults suggestion. Is that intended?

@jrobeson

This comment has been minimized.

Show comment
Hide comment
@jrobeson

jrobeson Feb 2, 2015

Contributor

there's an external library that already implements the xdg spec, is it possible to use that? https://github.com/dnoegel/php-xdg-base-dir/

Contributor

jrobeson commented Feb 2, 2015

there's an external library that already implements the xdg spec, is it possible to use that? https://github.com/dnoegel/php-xdg-base-dir/

@ntoniazzi

This comment has been minimized.

Show comment
Hide comment
@ntoniazzi

ntoniazzi Feb 2, 2015

Contributor

@alcohol It was not intended, and should be fixed now.

Contributor

ntoniazzi commented Feb 2, 2015

@alcohol It was not intended, and should be fixed now.

Merge remote-tracking branch 'parent/master'
Conflicts:
	src/Composer/Factory.php
@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Apr 30, 2015

Member

It seems detecting XDG support is a clusterfuck. http://i.imgur.com/9B7qW1J.png / https://i.imgur.com/gk0FJab.png are on Fedora and Debian, on ubuntu server I only get XDG_SESSION_ID which doesn't even relate to the XDG Base Dir spec.

I would love to move this forward (at last..) but I am not sure how to best proceed.. Just assume XDG on non-windows? Check for ~/.config and assume XDG then? Check all env vars for anything matching XDG and assume XDG?

@jrobeson I'd rather not add a dependency especially as it doesn't quite seem on par with what we need (cross platform and fallback to existing composer dirs, etc).

Member

Seldaek commented Apr 30, 2015

It seems detecting XDG support is a clusterfuck. http://i.imgur.com/9B7qW1J.png / https://i.imgur.com/gk0FJab.png are on Fedora and Debian, on ubuntu server I only get XDG_SESSION_ID which doesn't even relate to the XDG Base Dir spec.

I would love to move this forward (at last..) but I am not sure how to best proceed.. Just assume XDG on non-windows? Check for ~/.config and assume XDG then? Check all env vars for anything matching XDG and assume XDG?

@jrobeson I'd rather not add a dependency especially as it doesn't quite seem on par with what we need (cross platform and fallback to existing composer dirs, etc).

@jrobeson

This comment has been minimized.

Show comment
Hide comment
@jrobeson

jrobeson Apr 30, 2015

Contributor

XDG_SESSION_ID is unrelated. It's for systemd user sessions.

The environment variables XDG_DATA_HOME,XDG_DATA_DIRS, etc are used for overrides of the default configuration and thus not set by default and then XDG library basically checks for these environment variables and returns the appropriate fallbacks if they aren't set. It handles the differences to XDG_DATA_HOME, XDG_DATA_DIRS, etc automatically and prefers the appropriate one if set.

On Linux, we should assume .config , .cache , etc by default and create them if they don't exist. The OSX folks might have better defaults for their own directories, so I'm not sure what to do for them.

Many programs that adopt XDG after the fact tend to keep existing configurations/directories and use them if they exist, but use .config,.cache,etc on new installs.

Contributor

jrobeson commented Apr 30, 2015

XDG_SESSION_ID is unrelated. It's for systemd user sessions.

The environment variables XDG_DATA_HOME,XDG_DATA_DIRS, etc are used for overrides of the default configuration and thus not set by default and then XDG library basically checks for these environment variables and returns the appropriate fallbacks if they aren't set. It handles the differences to XDG_DATA_HOME, XDG_DATA_DIRS, etc automatically and prefers the appropriate one if set.

On Linux, we should assume .config , .cache , etc by default and create them if they don't exist. The OSX folks might have better defaults for their own directories, so I'm not sure what to do for them.

Many programs that adopt XDG after the fact tend to keep existing configurations/directories and use them if they exist, but use .config,.cache,etc on new installs.

@jrobeson

This comment has been minimized.

Show comment
Hide comment
@jrobeson

jrobeson Apr 30, 2015

Contributor

Here's how psysh initially implemented it: bobthecow/psysh@52bce7c

Contributor

jrobeson commented Apr 30, 2015

Here's how psysh initially implemented it: bobthecow/psysh@52bce7c

@ntoniazzi

This comment has been minimized.

Show comment
Hide comment
@ntoniazzi

ntoniazzi May 4, 2015

Contributor

So, we can do the following:

  • On Windows and OSX, we don't change anything
  • On Linux, we forget about migrating the conf :
    • if a .composer directory exists, we keep the current behavior
    • if not, we just assume XDG and use dnoegel/php-xdg-base-dir to get the correct location.

What do you think?

Contributor

ntoniazzi commented May 4, 2015

So, we can do the following:

  • On Windows and OSX, we don't change anything
  • On Linux, we forget about migrating the conf :
    • if a .composer directory exists, we keep the current behavior
    • if not, we just assume XDG and use dnoegel/php-xdg-base-dir to get the correct location.

What do you think?

@marcinant

This comment has been minimized.

Show comment
Hide comment
@marcinant

marcinant Jun 13, 2015

Bump. Any progress on this issue?

marcinant commented Jun 13, 2015

Bump. Any progress on this issue?

@johndrinkwater

This comment has been minimized.

Show comment
Hide comment
@johndrinkwater

johndrinkwater Jun 23, 2015

#1407 (comment) this seems the correct, though missing one caveat for people not using XDG, creating ~/.config/composer by default would be frustrating.

  • if ~/.composer exists, use that
  • if getHomeConfigDir() exists:
    • append "composer/" and use that
  • else create ~/.composer & use that

#1407 (comment)

On Linux, we should assume .config , .cache , etc by default and create them if they don't exist.

john@joran ~/code/ ±:master❯ env | grep XDG_.*HOME
XDG_DATA_HOME=/home/john/settings/data
XDG_STATE_HOME=/home/john/settings/state
XDG_CONFIG_HOME=/home/john/settings/config
XDG_CACHE_HOME=/home/john/settings/cache

johndrinkwater commented Jun 23, 2015

#1407 (comment) this seems the correct, though missing one caveat for people not using XDG, creating ~/.config/composer by default would be frustrating.

  • if ~/.composer exists, use that
  • if getHomeConfigDir() exists:
    • append "composer/" and use that
  • else create ~/.composer & use that

#1407 (comment)

On Linux, we should assume .config , .cache , etc by default and create them if they don't exist.

john@joran ~/code/ ±:master❯ env | grep XDG_.*HOME
XDG_DATA_HOME=/home/john/settings/data
XDG_STATE_HOME=/home/john/settings/state
XDG_CONFIG_HOME=/home/john/settings/config
XDG_CACHE_HOME=/home/john/settings/cache
@ntoniazzi

This comment has been minimized.

Show comment
Hide comment
@ntoniazzi

ntoniazzi Jul 22, 2015

Contributor

On windows : no change
On other systems :

  • if ~/.composer exists, use it
  • if XDG is active(1)
    • if XDG_CONFIG_HOME is set, append "composer" and use it
    • else create ".config/composer" and use it
  • else create "~/.composer" and use it

(1) @johndrinkwater about the caveat: exact XDG detection does not seem possible. For now, any environment variable starting with "XDG_" will trigger it. Seems like libreoffice doesn't care and creates a ".config/libreoffice" directory as a fallback to XDG_CONFIG_HOME. Maybe we could do the same?

Contributor

ntoniazzi commented Jul 22, 2015

On windows : no change
On other systems :

  • if ~/.composer exists, use it
  • if XDG is active(1)
    • if XDG_CONFIG_HOME is set, append "composer" and use it
    • else create ".config/composer" and use it
  • else create "~/.composer" and use it

(1) @johndrinkwater about the caveat: exact XDG detection does not seem possible. For now, any environment variable starting with "XDG_" will trigger it. Seems like libreoffice doesn't care and creates a ".config/libreoffice" directory as a fallback to XDG_CONFIG_HOME. Maybe we could do the same?

@jrobeson

This comment has been minimized.

Show comment
Hide comment
@jrobeson

jrobeson Jul 22, 2015

Contributor

I don't know the composer codebase. Can someone tell me how this PR handles the storage for the composer rollback files? It's important that they don't end up in .config/composer

Contributor

jrobeson commented Jul 22, 2015

I don't know the composer codebase. Can someone tell me how this PR handles the storage for the composer rollback files? It's important that they don't end up in .config/composer

@alcohol

This comment has been minimized.

Show comment
Hide comment
@alcohol

alcohol Jul 22, 2015

Member

Rollback files end up in the Composer home directory currently.

This PR keeps them there (but refers to it as data-dir).

Member

alcohol commented Jul 22, 2015

Rollback files end up in the Composer home directory currently.

This PR keeps them there (but refers to it as data-dir).

@ntoniazzi

This comment has been minimized.

Show comment
Hide comment
@ntoniazzi

ntoniazzi Jul 22, 2015

Contributor

data-dir points to one of the following locations:

  • $XDG_DATA_HOME/composer
  • ~/.local/share/composer
  • ~/.composer
Contributor

ntoniazzi commented Jul 22, 2015

data-dir points to one of the following locations:

  • $XDG_DATA_HOME/composer
  • ~/.local/share/composer
  • ~/.composer
Merge remote-tracking branch 'parent/master'
Conflicts:
	src/Composer/Factory.php

@Seldaek Seldaek merged commit b6df854 into composer:master Jan 18, 2016

2 checks passed

continuous-integration/appveyor AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

Seldaek added a commit that referenced this pull request Jan 18, 2016

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Jan 18, 2016

Member

@ntoniazzi many thanks for the extreme patience here :) It's finally in!

I tried it out on ubuntu doing mv ~/.composer ~/.config/composer && rm -rf ~/.config/composer/cache is enough to trigger a switch over to XDG mode (assuming you have one of the XDG_ env vars set at least..).

Member

Seldaek commented Jan 18, 2016

@ntoniazzi many thanks for the extreme patience here :) It's finally in!

I tried it out on ubuntu doing mv ~/.composer ~/.config/composer && rm -rf ~/.config/composer/cache is enough to trigger a switch over to XDG mode (assuming you have one of the XDG_ env vars set at least..).

@steffenweber

This comment has been minimized.

Show comment
Hide comment
@steffenweber

steffenweber Jan 18, 2016

Seems to be working fine on Gentoo Linux, thank you!

steffenweber commented Jan 18, 2016

Seems to be working fine on Gentoo Linux, thank you!

@EvanPurkhiser

This comment has been minimized.

Show comment
Hide comment
@EvanPurkhiser

EvanPurkhiser Apr 14, 2016

@ntoniazzi I'd like to extend a massive thank you for this. You're fighting the good fight to stop software from littering it's dotfiles in $HOME :-)

EvanPurkhiser commented Apr 14, 2016

@ntoniazzi I'd like to extend a massive thank you for this. You're fighting the good fight to stop software from littering it's dotfiles in $HOME :-)

@COLABORATI

This comment has been minimized.

Show comment
Hide comment
@COLABORATI

COLABORATI Aug 11, 2016

I just want to say thank you, too. One more piece of extra fiddling with backups gone away, thanks!

COLABORATI commented Aug 11, 2016

I just want to say thank you, too. One more piece of extra fiddling with backups gone away, thanks!

@marcinant

This comment has been minimized.

Show comment
Hide comment
@marcinant

marcinant Aug 11, 2016

👍 Thank you!

marcinant commented Aug 11, 2016

👍 Thank you!

@stefanotorresi

This comment has been minimized.

Show comment
Hide comment
@stefanotorresi

stefanotorresi Oct 3, 2016

can anyone report if this change breaks existing .travis.yml cache directives?

i.e.

cache:
  directories:
    - $HOME/.composer/cache

stefanotorresi commented Oct 3, 2016

can anyone report if this change breaks existing .travis.yml cache directives?

i.e.

cache:
  directories:
    - $HOME/.composer/cache
@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Oct 3, 2016

Member

It might indeed, to be safe you should define COMPOSER_HOME as being $HOME/.composer - I am not sure if travis VMs pass our checks for enabling XDG..

Member

Seldaek commented Oct 3, 2016

It might indeed, to be safe you should define COMPOSER_HOME as being $HOME/.composer - I am not sure if travis VMs pass our checks for enabling XDG..

@stefanotorresi

This comment has been minimized.

Show comment
Hide comment
@stefanotorresi

stefanotorresi Oct 3, 2016

@Seldaek apparently it doesn't, so stuff still ends up in $HOME/.composer 😅

stefanotorresi commented Oct 3, 2016

@Seldaek apparently it doesn't, so stuff still ends up in $HOME/.composer 😅

@alcohol

This comment has been minimized.

Show comment
Hide comment
@alcohol

alcohol Oct 3, 2016

Member

XDG environment variables are not set on travis as they run no desktop environment by default (especially not on the container jobs). So there it should still default to the "old" convention/directories.

Member

alcohol commented Oct 3, 2016

XDG environment variables are not set on travis as they run no desktop environment by default (especially not on the container jobs). So there it should still default to the "old" convention/directories.

aminztw pushed a commit to aminztw/composer that referenced this pull request Jan 1, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment