proper data dir handling and new possibilities

[MestreLion]

Dear devs,

I just posted a new branch, bugfix/datadir, that finally tackles the fragile definition of the data dir in a robust and path independent way. Now all code will correctly find it, without any need of string manipulation, trailing "/" assumptions or  other weird hacks (remember g.fix_data_dir() ?).

For the curious, the trick is code/g.py's __file__ builtin. g is always loaded as a module, so we can rely on this var to properly find ../data no matter where current dir is.

"Ok, great, kudos for you ML, but so what? Not worth a new topic.."

Sure, this is no big deal by itself. But let's think about the consequences and the world of new possibilities it allows:

- /All/ code that read files uses data_loc (now data_dir), directly or indirectly. That goes for music, fonts, sounds, translations,  data files. /everything/ is tied to the data dir.

- That was, until now, the very reason why ./Endgame_Linux launcher existed: solely to change current dir to game dir so paths would work.

- Being g.data_dir now an absolute, properly handled path, independent from current dir, /linux launcher is not needed anymore/. Game can be started from /anywhere/ with "python /path/to/es/singularity.py"  :)

- This probably means setup.py will now work for Linux! I didn't test this, but since the "must be in game dir" restriction is lifted, there is no reason for it not to work.

Phil once told me, "be bold". So, how about these future steps:

- Delete Endgame_Linux (and singularity shell script).

- Add a "#!/usr/bin/env python" shebang to singularity.py, and chmod +x it. BAM, new executable, E:S can now run from anywhere!

- Why is ./singularity.py a 1-liner that only imports ./code/singularity.py? Heck, copy all of its code to ./singularity.py, adjust imports, and ta-da! ./code/singularity.py is gone! ./singularity.py is now the entry module, the shell executable, and the file that handles argparse and starts the game, as it should be in any sane layout.

- setup.py can be used by user (or distro package maintainers) to actually install the game in Mac, Windows.. and Linux! As in *any* python app. No more silly "sorry, I don't work for linux. I must be in /usr/share/games or hell will break loose". We actualy /don't care/ where it will be installed/run. setup.py, .deb installer, or ~/downloads/im/only/testing/singularity.py, they all work fine

bugfix/datadir is ready to merge at http://code.google.com/r/rodrigosilva-singularity/ , and if you guys like the "bolder" suggestions, I can promptly create another branch for them.

Eager for your feedback,
ML

If

[Phil Bordelon]

On 04/27/2012 11:08 PM, MestreLion wrote:
> Dear devs,
>
> I just posted a new branch, bugfix/datadir, that finally tackles the fragile
> definition of the data dir in a robust and path independent way. Now all
> code will correctly find it, without any need of string manipulation,
> trailing "/" assumptions or other weird hacks (remember g.fix_data_dir() ?).
>
> For the curious, the trick is code/g.py's __file__ builtin. g is always
> loaded as a module, so we can rely on this var to properly find ../data no
> matter where current dir is.

Clever. Merged.

> - Delete Endgame_Linux (and singularity shell script).
>
> - Add a "#!/usr/bin/env python" shebang to singularity.py, and chmod +x it.
> BAM, new executable, E:S can now run from anywhere!

These are definitely fine.

> - Why is ./singularity.py a 1-liner that only imports ./code/singularity.py?
> Heck, copy all of its code to ./singularity.py, adjust imports, and ta-da!
> ./code/singularity.py is gone! ./singularity.py is now the entry module, the
> shell executable, and the file that handles argparse and starts the game, as
> it should be in any sane layout.

I'm more than a bit leery of this, if only because right now there's a clean
distinction between code/, where all the real code is, and the dummy
singularity.py that's really just "hey, import the stuff in code." Pushing
the code of singularity.py down one level makes the directory "code/"
ambiguous; it now means "all the code except for the stuff that we have to
do before we use it," which is ... inelegant.

As silly as it is to have a single-line file, I'm actually okay with that.

> Eager for your feedback,
> ML

Thanks again for your work on cleaning up the mess.

P

[MestreLion]

I totally agree this is merely cosmetics... the important part is the 2 points you agreed on: ./singularity.py is the new (executable) launcher, and ./singularity shell script die. (should ./Endgame_Linux symlink die too, or let's give distros some months to adapt?)

About cosmetics: there will still be a clear distinction from ./code ./singularity.py, although different from today: ./singularity.py is a boring place where settings are read, arguments are parsed, hardware is initialized and initial values are set, while ./code is the game itself.

In other words: ./singularity.py goes from "dummy launcher" to "boring setup". There's no game logic at all, and the fact it /ends/ with "menu_screen.show()" keeps the distinction from ./code pretty clear.

(... with an added bonus of deleting 1 more file... muwahahaha <- evil laugh. sort of)

But again, it is optional cosmetic :)

ML

[Phil Bordelon]

On 04/28/2012 12:59 AM, MestreLion wrote:

> I totally agree this is merely cosmetics... the important part is the 2
> points you agreed on: ./singularity.py is the new (executable) launcher, and
> ./singularity shell script die. (should ./Endgame_Linux symlink die too, or
> let's give distros some months to adapt?)

Kill it. Distros had to use their own wrapper scripts anyway, as they
almost certainly weren't shoving all of data/ and code/ into /usr/bin
to satisfy our directory requirements. Losing it's not going to affect
anyone meaningfully.

> About cosmetics: there will still be a clear distinction from ./code
> ./singularity.py, although different from today: ./singularity.py is a
> boring place where settings are read, arguments are parsed, hardware is
> initialized and initial values are set, while ./code is the game itself.
>
> In other words: ./singularity.py goes from "dummy launcher" to "boring
> setup". There's no game logic at all, and the fact it /ends/ with
> "menu_screen.show()" keeps the distinction from ./code pretty clear.
>
> (... with an added bonus of deleting 1 more file... muwahahaha <- evil
> laugh. sort of)
>
> But again, it is optional cosmetic :)

We can revisit this later, but for now just leave it as-is. I agree that
it's boring code, but it /is/ code, in a much more meaningful sense than
'import code.singularity,' so.

P

[MestreLion]

On Saturday, April 28, 2012 3:13:46 AM UTC-3, Phil Bordelon wrote:

On 04/28/2012 12:59 AM, MestreLion wrote:

> I totally agree this is merely cosmetics... the important part is the 2
> points you agreed on: ./singularity.py is the new (executable) launcher, and
> ./singularity shell script die. (should ./Endgame_Linux symlink die too, or
> let's give distros some months to adapt?)

Kill it.  Distros had to use their own wrapper scripts anyway, as they
almost certainly weren't shoving all of data/ and code/ into /usr/bin
to satisfy our directory requirements.  Losing it's not going to affect
anyone meaningfully.

You're the boss ;)

Done.
 

> About cosmetics: there will still be a clear distinction from ./code
> ./singularity.py, although different from today: ./singularity.py is a
> boring place where settings are read, arguments are parsed, hardware is
> initialized and initial values are set, while ./code is the game itself.
>
> In other words: ./singularity.py goes from "dummy launcher" to "boring
> setup". There's no game logic at all, and the fact it /ends/ with
> "menu_screen.show()" keeps the distinction from ./code pretty clear.
>
> (... with an added bonus of deleting 1 more file... muwahahaha <- evil
> laugh. sort of)
>
> But again, it is optional cosmetic :)

We can revisit this later, but for now just leave it as-is.

True, no need to discuss it now.

But let me just register now an argument so I won't forget it later, if we ever talk about this again:

There was also another issue besides purely cosmetic: ./singularity.py, even being a 1-liner like now, is /not/ an optional wrapper to ./code/singularity.py. It plays a /vital/ role in establishing ./code directory as a package, something that can't be done from within. Running ./code/singularity.py directly will /not/ work, as all references to code.xxx in all modules will be invalid. So ./singularity.py /existence/ is mandatory, while ./code/singularity.py is optional: it is never used or imported by any other module. it runs just once and its job is over forever. It's a stranger in a dir with no friends.

(I'm imagining now a comic strip where singularity.py laughs at  ./code/singularity.py saying "who's the dummy now, loser?" :P)

So I did this:
- deleted singularity and its symlink
- chmod'ed +x singularity.py
- Adjusted README and setup.py (also incorporating some code from defunct testing/setup)
- Adjusted singularity and code.singularity headers to clarify their respective roles.

That said... public/launcher is ready to merge

ML