Skip to content

Consider providing template config file in docs instead of writing to disk #8552

Closed

Description

@astrofrog

If no config file exists in the user's home directory, we currently create one. We also have logic to check if the config file is still the default one and update it if astropy is updated. However, having a config file, even set to defaults, can cause issues with concurrency, e.g. #7290

One solution would be to never write a default config file to the user's home directory but instead show the default config file in the docs, like Matplotlib does for the matplotlibrc:

https://matplotlib.org/users/customizing.html

This would make the use of config files opt-in. Changing to do this wouldn't affect any existing user, so if we switched to simply showing the default config in the docs, nothing would break, it just would prevent config files from being re-created or created in future.

Activity

  1. Cadair commented on Apr 4, 2019

    @Cadair
    Member

    +1 on this from me, we don't write SunPy's config out by default either.

  2. duncanmmacleod commented on Apr 4, 2019

    @duncanmmacleod
    Contributor

    +1 from me, I've been struggling with the same failures as demonstrated in #7290 when using a shared (NFS) file system across multiple hosts, and multiple astropy versions.

  3. pllim commented on Apr 4, 2019

    @pllim
    Member

    There was an attempt by @Cadair to address the underlying problem at #8237 .

  4. pllim commented on Apr 4, 2019

    @pllim
    Member

    Previous attempts include #5907 by @funbaker and #5828 by @adrn .

  5. pllim commented on Apr 4, 2019

    @pllim
    Member

    p.s. Probably too late for 3.2 but would be a good one for 4.0 if we can get to it.

  6. astrofrog commented on Apr 4, 2019

    @astrofrog
    MemberAuthor

    I still think we should consider the approach I'm mentioning here of not even writing the config file in the first place. That would be easy to do for 3.2.

  7. pllim commented on Apr 4, 2019

    @pllim
    Member

    But not writing it now will not solve the problem of people running different versions of Astropy in a shared directory? One of the version is going to be incompatible with whatever config that was last written there and crash anyway. What problem are we trying to solve here?

  8. astrofrog commented on Apr 4, 2019

    @astrofrog
    MemberAuthor

    It will solve the case of one user running many jobs with concurrent processes trying to create/read their config file.

  9. added this to the v3.2 milestone on Apr 4, 2019
  10. Cadair commented on Apr 4, 2019

    @Cadair
    Member

    #8237 is rather orthogonal to this, it's more for affiliated package maintainers rather than users.

    The approach we are taking in SunPy to this is to not write a file by default but to provide a helper which writes the default file to the correct location for the user to customize.

  11. bsipocz commented on Apr 11, 2019

    @bsipocz
    Member

    Is there any chance to get this nailed down in the next week? If not please remove milestone, or remilestone if it's high enough priority for 4.0.

  12. Cadair commented on Apr 15, 2019

    @Cadair
    Member

    Ok, so it looks like solving this makes solving #8237 easier as well, so I am on it.

  13. Cadair commented on Apr 16, 2019

    @Cadair
    Member

    This is now fixed in #8237 if people want to take a look at it.

  14. removed this from the v3.2 milestone on May 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions