Mailing-List: contact notifications-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ant.apache.org
Date: Wed, 1 Nov 2017 13:46:00 +0000 (UTC)
From: "Simon Ochsenreither (JIRA)" <jira@apache.org>
To: notifications@ant.apache.org
Message-ID: <JIRA.12758891.1417527260000.120892.1509543960113@Atlassian.JIRA>
In-Reply-To: <JIRA.12758891.1417527260000@Atlassian.JIRA>
References: <JIRA.12758891.1417527260000@Atlassian.JIRA> <JIRA.12758891.1417527260358@jira-lw-us.apache.org>
Subject: [jira] [Commented] (IVY-1502)  Be a nice freedesktop citizen, move
 the ~/.ivy to the appropriate location
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 01 Nov 2017 13:46:06 -0000


    [ https://issues.apache.org/jira/browse/IVY-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16234078#comment-16234078 ] 

Simon Ochsenreither commented on IVY-1502:
------------------------------------------

Yes, the original bug report was incorrect in some details, but I didn't want to create a new ticket, duplicating the overall intent of this one.

>  Switching to the layout recommended by freedesktop might feel natural to Linux users, or rather users of Linux distros that have adopted the spec, but will be completely surprising to Windows and probably Mac users.

I'm not suggesting such a thing, that would be a pretty bad idea. What I want is that Ivy follows platform standards on _all_ platforms:

- the XDG base directory specification on Linux,
- the SpecialFolder enumeration on Windows, and
- the Standard Directories rules on macOS.

This is really important, because Windows makes a difference between data that is roaming (is copied across the network if a user logs into his account on a different machine) and data that is machine-local.

macOS also has a dedicated cache directory that is handled in a special way by applications (for instance macOS' backup tool ignores it) and the operating system (when disk space runs low).

It's pretty much the same for Linux.

My proposal is that

- configuration should go into the configuration folder specified by the operating system (for instance .config/ivy/ on Linux)
- artifacts from repositories should go into the cache folder specified by the operating system (for instance .cache/ivy/ on Linux)
- locally published artifacts should go int the application data directory (for instance .local/share/ivy/ on Linux)

The last two points provide a large benefit, because then it is possible to delete .cache without losing locally published artifacts that cannot be restored from remote repositories. Deleting .cache should have no impact on a user expect his program running a bit slower until the cache has been restored.

I understand your concerns regarding documentation and support. This could be addressed by Ivy printing an informative message on startup, pointing to the directories used, or adding a command line flag that does the same.

>  Be a nice freedesktop citizen, move the ~/.ivy to the appropriate location 
> ----------------------------------------------------------------------------
>
>                 Key: IVY-1502
>                 URL: https://issues.apache.org/jira/browse/IVY-1502
>             Project: Ivy
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.3.0
>         Environment: linux
>            Reporter: PerfectCarl
>            Priority: Minor
>
> According to the XDG specification [1], there is a better way to store the user specific data of an application by dumping in new hidden folder in ~/.
> More information about it can be found [2]
> The specification defines places to store the data so that the user profile can be updated and moved properly while reducing some weird bugs.
> Those places would be ~/.local/ivy or ~/.cache/ivy and other (depending on the data stored)
> [1]: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
> [2]: https://ploum.net/207-modify-your-application-to-use-xdg-folders/


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)