You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Consider providing template config file in docs instead of writing to disk #8552
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:
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.
+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.
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.
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?
#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.
Activity
Cadair commentedon Apr 4, 2019
+1 on this from me, we don't write SunPy's config out by default either.
duncanmmacleod commentedon Apr 4, 2019
+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.
pllim commentedon Apr 4, 2019
There was an attempt by @Cadair to address the underlying problem at #8237 .
pllim commentedon Apr 4, 2019
Previous attempts include #5907 by @funbaker and #5828 by @adrn .
pllim commentedon Apr 4, 2019
p.s. Probably too late for 3.2 but would be a good one for 4.0 if we can get to it.
astrofrog commentedon Apr 4, 2019
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.
pllim commentedon Apr 4, 2019
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?
astrofrog commentedon Apr 4, 2019
It will solve the case of one user running many jobs with concurrent processes trying to create/read their config file.
Cadair commentedon Apr 4, 2019
#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.
bsipocz commentedon Apr 11, 2019
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.
Cadair commentedon Apr 15, 2019
Ok, so it looks like solving this makes solving #8237 easier as well, so I am on it.
Cadair commentedon Apr 16, 2019
This is now fixed in #8237 if people want to take a look at it.