Package-assisted path handling, via @EdwinTh

[jennybc]

Thanks @EdwinTh for blogging your approach!

Use to enrich discussion about ways to make paths more robust across users and computers.

https://edwinth.github.io/multiperson-project/

@hadley also got @EdwinTh's blessing to do a mini code review & makeover, which is here:

tidyverse/design#56

Repeating a comment I made there, in case I can tempt @EdwinTh into a discussion of it here:

if its better to swap configuation for convention

Yeah, why not force users to follow the same convention within their home dir? Or have a helper function in the package that interactively creates a symlink from each user's idiosyncratic data storage choice to ~/project_name/data. A user would do this once, when they start working on the project.

Basically get the varying code / logic out of the package itself and just make sure each user's local situation can "explain itself" to the package.

[jennybc]

A way to describe the intent of INTERNAL_PACKAGE::save_as_rds(): it's just like here::here() but substituting the conventions of INTERNAL_PACKAGE for here's set of criteria re: the basis for building paths.

All the processing of Sys.info()["nodename"] and Sys.info()['user'] plays the same role as here (or rprojroot) looking for a DESCRIPTION file, a .git directory, etc.

[EdwinTh]

I am not only compliant, I am also very easily tempted...

why not force users to follow the same convention within their home dir?
Users typically have a certain set up of their local system, each organized to their own logic and preferences. Some like it deep, some like it shallow (personally I am a very shallow person). This way each can place the folder where it makes most sense to him or her.

have a helper function in the package that interactively creates a symlink
Thats an interesting thought. So, you mean that package points to the same location on every system, but that on this location the user creates the pointer to the its personal folder? I think in ease of use it would not make much of a difference. Are there other advantages over our approach in your opinion?

A way to describe the intent of INTERNAL_PACKAGE::save_as_rds(): it's just like here::here()
I have not yet used here so I cannot comment on this.

[jennybc]

have a helper function in the package that interactively creates a symlink

Thats an interesting thought. So, you mean that package points to the same location on every system, but that on this location the user creates the pointer to the its personal folder? I think in ease of use it would not make much of a difference.

Yes, exactly.

Are there other advantages over our approach in your opinion?

I think it's an advantage that you don't have to edit the source of the package each time a team member comes on board or decides to rename a folder. As it stands, your package source actually needs to change if I am user2 and I decide to keep the data in "cuddly_brocolli/fluffy_otter/" instead of "cuddly_brocolli/lively_hamster". Ditto for when user3 and user4 join the team.