On Sat, Feb 1, 2014 at 12:34 PM, Donald Stufft <donald@stufft.io> wrote:

 

On Sat, Feb 1, 2014, at 12:26 PM, Brett Cannon wrote:

 

 

 

 

On Sat, Feb 1, 2014 at 3:23 AM, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:

 

On Fri, 31/1/14, Brian Wickman <wickman@gmail.com> wrote:

 

> There are myriad other practical reasons.  Here are some:

 

Thanks for taking the time to respond with the details - they are good data points

to think about!

 

 

> Lastly, there are social reasons. It's just hard to convince most engineers

> to use things like pkg_resources or pkgutil to manipulate resources

> when for them the status quo is just using __file__.  Bizarrely the social

> challenges are just as hard as the abovementioned technical challenges.

 

I agree it's bizarre, but sadly it's not surprising. People get used to certain ways

of doing things, and a certain kind of collective myopia develops when it

comes to looking at different ways of doing things. Having worked with fairly

diverse systems in my time, ISTM that sections of the Python community have

this myopia too. For example, the Java hatred and PEP 8 zealotry that you see

here and there.

 

PEP 302 tried to unify this with get_data() and set_data() on loaders, but prior to Python 3.3 you just didn't have any guarantee that __loader__ would even be set, let alone have a loader with those methods. Paul can tell me if my hunch is off, but I assume the dream was that people would do `__loader__.get_data('asset.txt')` instead of `os.path.join(os.path.dirname(__file__), 'asset.txt')` to read something bundled with your package. But as Brian has pointed out, people just have habits at this point of assuming unpacked files and working off of __file__.

 

I know Daniel has said he wanted some concept of a listdir() on loaders so that they could basically act as a virtual file system for packages, but it would also require locking down what relative vs. absolute paths meant in get_data/set_data (i.e. is it relative to the loader in the package or the package itself? My pref is the latter for the case of reused loaders) and really pushing people to use the loader APIs for reading intra-package "files".

 

There's also the problem when you need to give a file that you have packaged as part of your thing to an API that only accepts filenames. The standard ssl module is one of these that i've run into recently.

 

Yes, that is definitely a design flaw in the ssl module that should get remedied. Did you file a bug to add a new API (whether new function or new parameters) to accept a file-like object or string instead?

 

-Brett

 

 

 

 

One of the things that's puzzled me, for example, is why people think it's reasonable

or even necessary to have copies of pip and setuptools in every virtual environment

- often the same people who will tell you that your code isn't DRY enough! It's

certainly not a technical requirement, yet one of the reasons why PEP 405 venvs

aren't that popular is that pip and setuptools aren't automatically put in there. It's a

social issue - it's been decided that rather than exploring a technical approach to

addressing any issue with installing into venvs, it's better to bundle pip and setuptools

with Python 3.4, since that will seemingly be easier for people to swallow :-)

 

I suspect it's also ignorance and differences in deployment strategies. Some people have such small deployments that hitting PyPI every time works, for others like Brian it can't be more than a cp w/ an unzip. Maybe the Packaging Users Guide could have a Recommended Deployment Strategies section or something. I doubt there are that many common needs beyond "pull from PyPI every time", "pull from your own wheel repo", "copy everything over in a single wheel/zip you unpack" so that people at least have a starting point to work from (especially if the instructions work on all platforms, i.e. no symlink discussions).

_______________________________________________

Distutils-SIG maillist  -  Distutils-SIG@python.org

https://mail.python.org/mailman/listinfo/distutils-sig

 

_______________________________________________

Distutils-SIG maillist  -  Distutils-SIG@python.org

https://mail.python.org/mailman/listinfo/distutils-sig