Well, I, for one, am not terribly happy with either solution -- you see, the
problem is that these days, it's hard to tell which modules will end up
importing astropy, which then results in either a warning message if I'm
lucky (yes, I know I could shut it up) or the loading of user-specific
configuration if a user starts the server in debug mode if I'm unlucky.

Setting XDG_CONFIG_HOME early on is tricky because I'd actually like to
point it to a server-defined position, which I only have available when
my the server's configuration is loaded. Making sure that has happened
before an import of anything pulling in astropy is possible, but feels a
bit brittle.

The context manager could, of course, control the whole server process.
But it has the same issue: Much rather mkdtemp-ing something somewhere,
I'd much rather have a controlled location, which I'd only get after my
own configuration is available (e.g., in case I later want server
operators to use a well-defined, server-specific configuration), which
is again not easy to ensure.

So, what I've been doing so far is exploit an implementation detail: a

	import __builtin__
	__builtin__._ASTROPY_SETUP_ = True

very early on. If something like that became sanctioned use, I'd be a
happy camper.

Abusing builtin is, of course, not ideal. But couldn't astropy use a
documented environment variable (ASTROPY_USE_BUILTIN_CONFIG?) here? I'd
suspect it might help your setup code, too.

[Disclosure: I'm working with @funbaker, so this isn't really an
independent opinion]

Uh oh!

Suppress configuration file loading #5899

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions