On 2 February 2017 at 06:34, René Dudfield <ren...@gmail.com> wrote:
> Whilst naming is important, the name of the package doesn't need to be the
> name of the Game. I've worked on projects where the company name, and app
> name changed at least three times whilst the package name stayed the same.
> So I don't think people need to worry so much. Also, it's not too hard to
> change the package name later on.
>
>
> My vote would be to follow the python sampleproject way of doing things.
>
That gets my vote as well. If you're putting it on PyPI, sooner or later
you have to give the package a good name (at least, not the same name as
every other game's package). We can encourage people to use relative
imports (from . import foo) which makes it less work to rename.
> Data folder, and "get_data".
>
> 2). The other aspect I'm not sure of is having a data folder outside of
> the source folder. Having it inside the source folder means you can more
> easily include it inside a zip file for example. It also makes packaging
> slightly easier. Since you can just use from within a MANIFEST.in a
> recursive include of the whole "mygamepackage" folder.
>
> Having data/ separate is the choice of the sampleproject, and the
> skellington.
>
> I haven't really seen a modern justification for keeping data out of the
> package folder?
>
My vote would be for it to go inside the package, and for the skeleton to
provide a bit of code like this:
DATA_DIR = os.path.join(dirname(abspath(__file__)), 'data')
def find_data(*path):
return os.path.join(DATA_DIR, *path)
This is roughly what I recommend in Pynsist's FAQ.
> I have vague recollections of reasons being: 'because debian does it'. My
> recollection is that Debian traditionally did it to keep code updates
> smaller. Because if you only change 1KB of source code, there's no point
> having a 20MB update every time.
>
Linux packagers like to put data files in /usr/share to comply with the
filesystem hierarchy spec. However, with the snippet of code I gave above,
it's easy for them to patch DATA_DIR = '/usr/share' and move the files out.
> A bonus of keeping data separate is that it forces you to use relative
> addressing of file locations. You don't hardcode "data/myfile.png" in all
> your paths. Do we recommend the python way of finding the data folder? This
> is package_data, and data_files setup attributes. https://github.com/pypa/
> sampleproject/blob/master/setup.py
>
Actually, I think that's more of a risk if it's a separate top-level
directory, because then 'data' is going to be in the CWD when you run it as
a developer.
> They (package_data) are a giant pain. One, because they require mentioning
> every single file, rather than just the whole folder. Two, because they
> require you updating configuration in both MANIFEST.in and setup.py. Also,
> there are different files included depending on which python packaging
> option you use.
>
Agreed that they are a giant pain. They don't quite require mentioning
every single file, as you can glob directories, but you do need to mention
every subdirectory, at least for package_data.
This is one of the things that prompted me to write a packaging tool called
'flit', which doesn't require this. I don't know that it's quite ready to
be pushed on people in a game skeleton, though.
> Another issue is that, using the python way pkg_resources from setuptools
> needs to be used at runtime. pkg_resources gets you access to the resources
> in an abstract way. Which means you need setuptools at runtime (not just at
> install time). There is already work going into keeping that separate here:
> https://github.com/pypa/pkg_resources So I'm not sure this will be a
> problem in the next months.
>
Ugh, I avoid pkg_resources at all costs. If you use package_data (as
opposed to data_files), it's not necessary; see my snippet above.
> I haven't confirmed if pkg_resources works with the various .exe making
> tools. I've always just used file paths. Thomas, does it work with Pynsist?
>
I haven't tried, but I'd guess it may well not work.
> Having game resources inside a .zip (or .egg) makes loading a lot faster
> on many machines. pkg_resources supports files inside of .egg files. So, I
> think we should consider this possibility.
>
I've heard this claim made before, but I haven't seen numbers. Having
resources inside a zip file is awkward if you need to pass a file path or a
file handle to other libraries: you have to extract it and write it to a
temporary file before you can pass it in. If the performance difference is
important, I'd favour writing some helper routines using the zipfile module
rather than doing anything with pkg_resources.
