Just come to my mind data test related to a package would be a natural
candidate:
mypack
|- __init__.py
|- test
|- __init__.py
|- test0.py
|- data
|- data.for.test0.dat
It is natural deploying them as part of an installer file.
I don't see why another indirection layer is required here: you have the
test.__file__ or the inspect.getfile *already*.
What makes so special this case or a very similar one (eg. po files,
images files for a gui based app, etc.)?
Is there any reason to invent/introduce something else?
I hope this helps,
Antonio
Vinay Sajip wrote:
Tarek Ziadé<tarek<at> ziade.org> writes:
Having a indirection like distutils2's resources allows the data files
to live alongside the code
in development and to be installed wherever that's desired by the
distro, without breaking
the code as long as it uses the indirection function to find back the file.
Since the indirection is provided by a file that can be browsed in the
metadata directory,
it means anyone can get the file location by using the API we provided.
Yes, but it seems like you're assuming everything's always installed in a
conventional way and not, say, deployed in a .zip. I'm not disputing what you
said - get_file_path and get_resource_path are still there in distlib - but I'm
not sure that there's *never* a case for data located in packages.
Regards,
Vinay Sajip
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
