calendar.dat needs an absolute path

[Ramana Kumar]

💥 currently you can only call track/untrack from one directory (the one in which your calendar.dat resides) if you want the cached authentication data to work. (this is with the python3 version of the gcalapi) It should probably be given an absolute path instead... though I don't know what it should be...

[Jeff Alstott]

Ah crap. Now I have calendar.dat files strewn around every directory that I've called track from.

[Ramana Kumar]

if you, as a python expert, have a good suggestion for what absolute path would be appropriate, please suggest it (or submit a pull request!). also, it's not so hard to find ~ -name calendar.dat (replace ~ with / if you've been really adventurous)

[Jeff Alstott]

It's not really a Python specific issue, right? It's a question of where we
can stick a file and be sure it'll still be there. How about the Glock
directory itself? Since we're needing to ln to it anyway, hopefully that
directory's location is stable.

On Wed, Nov 19, 2014 at 4:43 PM, Ramana Kumar [e-mail]
wrote:

if you, as a python expert, have a good suggestion for what absolute path
would be appropriate, please suggest it (or submit a pull request!). also,
it's not so hard to find ~ -name calendar.dat (replace ~ with / if you've
been really adventurous)

—
Reply to this email directly or view it on GitHub
#7 (comment).

[Ramana Kumar]

That would be fine except we don't know where the Glock directory is going to be on various people's computers - it depends where you clone the repository. The only option I can see to use it is to make another configuration variable (like le_nom_de_calendrier) where you put in the path you want for the calendar.dat file. (Unless python has some way of knowing not the current working directory of the script being run but the directory where the script is on disk, which seems unlikely, since it might not even exist (e.g. the script was typed into the REPL and never saved).)

[Jeff Alstott]

os.getcwd()

Does that perform the needed elements?

On Wed, Nov 19, 2014 at 5:01 PM, Ramana Kumar [e-mail]
wrote:

That would be fine except we don't know where the Glock directory is going
to be on various people's computers - it depends where you clone the
repository. The only option I can see to use it is to make another
configuration variable (like le_nom_de_calendrier) where you put in the
path you want for the calendar.dat file. (Unless python has some way of
knowing not the current working directory of the script being run but the
directory where the script is on disk, which seems unlikely, since it might
not even exist (e.g. the script was typed into the REPL and never saved).)

—
Reply to this email directly or view it on GitHub
#7 (comment).

[Jeff Alstott]

Can also do:

os.path.dirname(os.path.abspath(file))

http://stackoverflow.com/questions/3430372/how-to-get-full-path-of-current-directory-in-python

On Wed, Nov 19, 2014 at 5:07 PM, Jeff Alstott [e-mail] wrote:

os.getcwd()

Does that perform the needed elements?

On Wed, Nov 19, 2014 at 5:01 PM, Ramana Kumar [e-mail]
wrote:

That would be fine except we don't know where the Glock directory is
going to be on various people's computers - it depends where you clone the
repository. The only option I can see to use it is to make another
configuration variable (like le_nom_de_calendrier) where you put in the
path you want for the calendar.dat file. (Unless python has some way of
knowing not the current working directory of the script being run but the
directory where the script is on disk, which seems unlikely, since it might
not even exist (e.g. the script was typed into the REPL and never saved).)

—
Reply to this email directly or view it on GitHub
#7 (comment).

[Ramana Kumar]

"You can't directly determine the location of the main script being executed. After all, sometimes the script didn't come from a file at all. For example, it could come from the interactive interpreter or dynamically generated code stored only in memory."

from
http://stackoverflow.com/questions/2632199/how-do-i-get-the-path-of-the-current-executed-file-in-python

(By the way I did try file and it said it was not defined.)

I think you should just set it manually, maybe with a default of $HOME/.calendar.dat.

[Jeff Alstott]

Could we assume that, given the use case of making symbolic links and what
not, that the script will always be a file? Or am I missing something?

I'd be perfectly happy with setting it manually.

On Wed, Nov 19, 2014 at 5:26 PM, Ramana Kumar [e-mail]
wrote:

"You can't directly determine the location of the main script being
executed. After all, sometimes the script didn't come from a file at all.
For example, it could come from the interactive interpreter or dynamically
generated code stored only in memory."

from

http://stackoverflow.com/questions/2632199/how-do-i-get-the-path-of-the-current-executed-file-in-python

(By the way I did try file and it said it was not defined.)

I think you should just set it manually, maybe with a default of
$HOME/.calendar.dat.

—
Reply to this email directly or view it on GitHub
#7 (comment).