Closed davidlatwe closed 4 years ago
- Make avalon.Session available right after import avalon, without io.install.
This makes the import somewhat magical because it would be unclear to the end user as to when exactly the state from the local environment got copied. For example, I'd imagine this to work:
import avalon.api
import os
os.environ["AVALON_ASSET"] = "hero"
avalon.api.install()
Whereas with that change we'd have to delay the import of avalon, which feels odd to me personally.
Just wondering @davidlatwe what in particular did you feel off about Avalon requiring to trigger an install()
to have its settings/session available? Were you having issues with actually installing something?
- Make avalon.Session always sync with os.environ
If that's the case, why not always just directly query os.environ
and disregard api.Session
? I believe the end goal was exactly that one could operate changes to the Session without influencing the local environment.
When I first met with avalon I was actually confused that it is called Session
. It is not session at all (at least not what they taught me in school) but current context of database i/o helper as you described and it is actually filled with os.environ
so my question is: Why to duplicate same data in 2 singleton dictionaries?
what in particular did you feel off about Avalon requiring to trigger an install() to have its settings/session available? Were you having issues with actually installing something?
I notice and start thinking about this was because I was testing something, and I don't require database at the time but I still need to run io.install
and wait for the connection to complete before I can access avalon.Session
for my test.
Not a big problem to wait for a few seconds, but that's the motivation I forgot to mention, sorry about that.
This makes the import somewhat magical
Good point, you are right.
Why to duplicate same data in 2 singleton dictionaries?
I think Roy just answered it : :point_down:
I believe the end goal was exactly that one could operate changes to the Session without influencing the local environment.
That's the end goal, yes.
The reason I think that they should be synced is to avoid duplicated values in global scope, and one should make an explicit copy if you want to change it.
But this might break the backward compatibility...
Hmmm, I think the only way to solve my original problem and make sense to everyone is like this
def init_session():
api.Session.update(io._from_environment())
Or making io._from_environment()
public ?
But still, feeling a bit danger for letting api.Session
be able to change in anywhere and apply to everywhere.
Am I thinking too much ? :/
I think io has installed
boolean. Not sure I've undestood original problem but you probably can use that (or add something similar?)
No, that's not what I am looking for, what I am looking is a good way to separate the initiating of api.Session
from io.install
.
But I am closing this for now, because the benefit could get from the proposal is less then the issues that may produce. Need a much more stronger motivation and much more specific problem.
Problem
avalon.Session
is empty untilio.install()
, wouldn't one expect theavalon.Session
has the context right afterimport avalon
?Because, from my understanding,
avalon.Session
is the current Avalon environment context, butio.install
is meant to establish the database connection. These were different concepts, and the nameSession
implies that it holds the current Avalon context, one wouldn't knowio.install
is required in prior.Next, I am NOT sure whether this should be considered as a problem or not, but after
avalon.Session
updated fromos.environ
, one still able to change Avalon environment variables inos.environ
but those changes will not reflect toavalon.Session
and vise versa.Maybe they should be synced ?
Proposal
avalon.Session
available right afterimport avalon
, withoutio.install
.avalon.Session
always sync withos.environ
Implementation
I am not sure about proposal 1), since it's related to the schema validation and still pending on #432.
But for proposal 2), maybe this ?
Please let me know what you think :)