On Tue, Feb 9, 2021 at 12:28 AM Inada Naoki <songofaca...@gmail.com> wrote:
> It makes problem too hard, complex. It leads we can not fix anything > at all by Python 3.10. > We can add Unix support later if it is really worth enough. It is not > backward incompatible change. > yes and no -- if we don't anticipate supporting Unix, then we may well come up with a solution that won't work well there. And if we do have a solution that will work well there, whynot turn it on? But anyway, you are quite right that it's a very narrow use case, so if you think it'll really hold things up then we can abandon that. > When using docker, it's very easy to put an environment variable. > You don't need to worry about "it will break existing legacy Python > application in same container." You can just create one container for > one application. > So I don't think it is enough reason to.add complexity. > Indeed, that is kind of the point of Docker :-) But the same issue could (though less likely) comeup for other *nix deployments -- I'd still like to have one place to specify what my Python application needs to run. Not a huge deal, but would be good. Without more concrete idea, such rough lead this thread to maze. > Well, I've been trying to get help with a more concrete idea in this thread. That's why I've specified what I think are the requirements -- we can't have a solution without agreeing on the requirements first. I'm still not sure if the requirement to make it easily installable into an environment without an extra step hasn't been discussed because it's technically impossible / difficult, or if no one else thinks it's worth doing at all. I guess either way, it's time to abandon the idea. > Note that UTF-8 mode must be enabled before any path config on Unix. > So it is almost impossible to enable UTF-8 mode using tools like pip. > That is the challenge, yes. But can pip put files outside of site-packages? I suspect not. > If your idea is just putting `python.ini` (or `python.cfg`) in bin/ or > Scripts/ directory from pip/conda package, I don't think it is just a > hack, not a best practice. It will cause file conflict error very > easily. > That is my idea -- at least for conda. But would it cause any more conflict than installing a package of a particular version? But this might be a case for using the pyenv.cfg file -- that IS intended to be manipulated by the environment tool. Though yes, having it looked for outside of the dir where python lives is not good. Have you arrived at a concrete proposal at this point? -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OCXXSMRH3FHE4Q56DFYUXAQSDY45PC6Y/ Code of Conduct: http://python.org/psf/codeofconduct/
