[issue12113] test_packaging fails when run twice
Alexis Metaireau added the comment: Same here, cannot reproduce the issue. I wasn't able to reproduce it even before Tarek's commit so I suppose his commit didnt changed anything regarding this hash problem. Antoine & Tarek, does the attached additional test reproduces the issue on your installation? -- assignee: tarek -> alexis keywords: +patch resolution: fixed -> status: closed -> open Added file: http://bugs.python.org/file22091/serve_twice.patch ___ Python tracker <http://bugs.python.org/issue12113> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12391] packaging install fails to clean up temp files
Alexis Metaireau added the comment: I'm +1 on applying this patch as well. Removing files in the tmp directory is far better than letting the OS doing so. -- ___ Python tracker <http://bugs.python.org/issue12391> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8668] Packaging: add a 'develop' command
Alexis Metaireau added the comment: Carl, I believe that's this one: http://wiki.python.org/moin/UsecasesOfDevelop -- ___ Python tracker <http://bugs.python.org/issue8668> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12697] timeiot documention still refers to the timeit.py script
New submission from Alexis Metaireau : The example section of the timeit documentation still refers to "timeit.py", and isn't using the "python -m timeit" syntax used above. http://docs.python.org/library/timeit.html#examples I'm not sure when and if the timeit.py script has been removed from the python installation (and I'm not sure on where to look for this). The timeit.py docstring also refers to this "old" syntax. Should we update it? All credit for this report goes to Boris Feld. -- assignee: alexis components: Library (Lib) messages: 141663 nosy: alexis priority: low severity: normal status: open title: timeiot documention still refers to the timeit.py script versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue12697> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12697] timeiot documention still refers to the timeit.py script
Changes by Alexis Metaireau : -- nosy: +Boris.FELD ___ Python tracker <http://bugs.python.org/issue12697> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12697] timeit documention still refers to the timeit.py script
Changes by Alexis Metaireau : -- title: timeiot documention still refers to the timeit.py script -> timeit documention still refers to the timeit.py script ___ Python tracker <http://bugs.python.org/issue12697> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6203] 3.x locale does not default to C, contrary to the documentation and to 2.x behavior
Alexis Metaireau added the comment: Maybe could it be useful to specify in the documentation that getlocale() is not intended to be used to get information about what is the locale of the system? It's not explained currently and thus it's a bit weird to have getlocale returning (None, None) even if you have your locales set. -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue6203> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6203] 3.x locale does not default to C, contrary to the documentation and to 2.x behavior
Alexis Metaireau added the comment: I see two different things here: 1) the fact that getlocale() doesn't return (None, None) on some python versions 2) the fact that having it returning (None, None) by default is a bit misleading as users may think that getlocale() is tied to environment variables. That's what was at the origin of #12699 My last remark is about the second bit. Maybe should I start a new issue for this? -- title: 3.x locale does not default to C,contrary to the documentation and to 2.x behavior -> 3.x locale does not default to C, contrary to the documentation and to 2.x behavior ___ Python tracker <http://bugs.python.org/issue6203> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12726] explain why locale.getlocale() does not read system's locales
New submission from Alexis Metaireau : The documentation about locale.getlocale() doesn't talk about the fact that the locale isn't read from the system locale. Thus, it seemed strange to have locale.getlocale() returning (None, None). As it seems to be the expected behaviour, it seems useful to specify this in the documentation and make it explicit. I'm okay to write a patch and apply it. This issue is related to #6203, but does not supersede it (the two conversations are discussing two different things). -- assignee: alexis components: Documentation messages: 141897 nosy: alexis, feth priority: normal severity: normal status: open title: explain why locale.getlocale() does not read system's locales ___ Python tracker <http://bugs.python.org/issue12726> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8668] Packaging: add a 'develop' command
Alexis Metaireau added the comment: _run_setuptools_install is only intended to support setuptools setup.py, converting .egg-info to .dist-info, internally. IMO, you should not care about the differences between setuptools/distutils1/setuptools at this level, as it should be taken care at the install level. When installing old setuptools-based setup.py, the .egg-info should be gone, replaced by a shiny new .dist-info folder. I'm not sure why you're talking about it in the context of develop, can you clarify this? -- ___ Python tracker <http://bugs.python.org/issue8668> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8668] Packaging: add a 'develop' command
Alexis Metaireau added the comment: IOW, in my opinion, support for setuptools develop command is not needed in packaging core, and still be taken care directly be the users wanting to run python setup.py develop: I don't see any reason to make it avaible on the stdlib. -- ___ Python tracker <http://bugs.python.org/issue8668> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8668] Packaging: add a 'develop' command
Alexis Metaireau added the comment: Yep, packaging is not keeping the .egginfo directories, or at least does not plan to keep them (It should be the case currently but I haven't checked recently) in the upcoming release, so I would go on removing support for setuptools' develop command here :) -- ___ Python tracker <http://bugs.python.org/issue8668> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8668] Packaging: add a 'develop' command
Alexis Metaireau added the comment: On 08/18/2011 05:54 PM, higery wrote: > Then do you also mean support that for setuptools install is also not > necessary in packaging core? setuptools install is only supported in packaging because it's a widely used thing, and many python distributions are currently packaged using setuptools features in their setup.py > I think the current implemention way of Packaging 'install' command just offers an executing router to run a proper 'install', which users doesn't need to know. What packaging.install does is, if the project has been packaged using setuptools, relying on it to install the projects, while not letting it take care of the dependencies. Then, the .egginfo is converted to a .distinfo, so the way setuptools distributions are installed is *not* compatible with setuptools installation procedure. It is important to note that setuptools will *not* be a dependency for packaging, but rather the end user will be prompted to install it if it's not present and he wants to install a setuptools based project (or if what he's trying to install relies on setuptools based projects). The problem with the develop command seems different to my eyes: develop is used by developers, not by end users. Thus, proposing them to keep using the "old" setuptools develop command in packaging may seem like encouraging them to continue using setuptools. Rather, I would prefer to say: "well, if you want to use setuptools' develop command, you can continue to do so, but the way to go would probably to repackage your project using shiny new standards". That's one of the handles we have to help the transition to packaging, so taking this occasion seems important to me. -- ___ Python tracker <http://bugs.python.org/issue8668> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12703] Improve error reporting for packaging.util.resolve_name
Alexis Metaireau added the comment: Thanks Rémy, About testing, I would go for modules with errors in it and check that when imported trough this function it does what it is supposed to do. IOW: 1. Create a test python module with errors in their definition (Throw an exception would do the trick) 2a. Try to load this python module, check that the exception is the one thrown in the module 2.b Check that loading a non existing modules still tell us that the module doesn't exist 2.c Check that importing something existing works, trough this function. Hope I'm clear enough, thanks again, Alexis -- ___ Python tracker <http://bugs.python.org/issue12703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8190] Add a PyPI XML-RPC client module
Alexis Metaireau added the comment: Please, can you be a bit more precise about the missing features ? I'll be glad to cover them. -- ___ Python tracker <http://bugs.python.org/issue8190> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8190] Add a PyPI XML-RPC client module
Alexis Metaireau added the comment: Yes, all the functions are covered. By the way, I've covered all the functions based on the pypi source code, not on the wiki. I'll update the wiki page with some examples soon :) -- ___ Python tracker <http://bugs.python.org/issue8190> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11357] Add support for PEP 381 -- Mirror Authenticity
Alexis Metaireau added the comment: Some nitpicks: In mirrors.get_server_key, the documentation is not up to date with your last changes (raises an error if there is a problem instead of returning None) You do use the name 'package' while talking about distributions or projects. Please be sure to use the right one on the right place (in your case, that's a project). A project (Django) contains releases (Django 1.1, 1.2, 1.3?) which contains distributions (sdist, bdist). The "verify_package" name could probably be changed in "is_trustable" or something like that, or raise an error (Otherwise, one can use verify_package thinking that it will actually check for something, without looking at the return value). In the documentation, you've mainly copy/pasted the PEP and provided examples on how to do the authenticity check with distutils2. While the second part is fine, I think that duplicating the PEP content on the documentation is probably an error: If the PEP changes, then the distutils2 documentation have to change as well. You probably can just refer on the PEP with a link. Adding informations on where did you find the sources of verify.py could be nice as well. Again, thanks for your work ! -- ___ Python tracker <http://bugs.python.org/issue11357> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11357] Add support for PEP 381 -- Mirror Authenticity
Alexis Metaireau added the comment: Antoine Pitrou on #python-dev made interesting remarks about the validation: 16:19 < __ap__> hmm the way the patch does validation is bogus 16:22 < __ap__> because it opens the URL a first time, validates it, then opens it a second time with urlopen() 16:22 < __ap__> without verifying the certificate on the second time 16:23 < __ap__> it should do the validation directly with urlopen() 16:23 < __ap__> (which probably requires defining a custom HTTPSHandler) -- ___ Python tracker <http://bugs.python.org/issue11357> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11921] distutils2 should be able to compile an Extension based on the Python implementation version
Alexis Metaireau added the comment: This raises a concern about python specific python implementations dependencies. We probably could extend PEP 345 in order to support things such as 'platform.python_implementation == "cpython"'. -- ___ Python tracker <http://bugs.python.org/issue11921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11921] distutils2 should be able to compile an Extension based on the Python implementation version
Alexis Metaireau added the comment: On 29/04/2011 18:20, Daniel Holth wrote: > New in version 2.6. Yep that's it. We would need to backport it in the python2 port of packaging (namely distutils2), but it would do the trick. I just started a discussion about that on the fellowship (to know if we can add this to PEP 345). -- Alexis -- title: distutils2 should be able to compile an Extension based on the Python implementation version -> distutils2 should be able to compile an Extension based on the Python implementation version ___ Python tracker <http://bugs.python.org/issue11921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5302] Allow package_data globs match directories
Alexis Metaireau added the comment: The MANIFEST.in is definitely gone in distutils2. Can we close that? (don't have the rights to do so ‑ it can be handy on distutils2 bugs) -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue5302> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5243] Missing dependency in distutils build
Alexis Metaireau added the comment: Has the patch been applied on distutils(1/2) ? -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue5243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue901727] extra_path kwarg to setup() undocumented
Alexis Metaireau added the comment: I've applied the patch on distutils2. This can now be closed. -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue901727> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6087] distutils.sysconfig.get_python_lib gives surprising result when used with a Python build
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue6087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2200] find_executable fails to find .bat files on win32
Alexis Metaireau added the comment: Have the patch been applied ? (the state is still open since last message) -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue2200> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7546] msvc9compiler.py: add .asm extension
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue7546> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue901727] extra_path kwarg to setup() undocumented
Alexis Metaireau added the comment: Still, the extra_path argument exists and can be used, it's worth to have it documented somewhere, especially if someone have done it. That's also true that apiref.rst is outdated in d2, and will need a complete reshape :) -- ___ Python tracker <http://bugs.python.org/issue901727> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1083299] Distutils doesn't pick up all the files it should.
Changes by Alexis Metaireau : -- components: -Distutils2 nosy: +alexis ___ Python tracker <http://bugs.python.org/issue1083299> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue1597850> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294032] Distutils writes keywords comma-separated
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue1294032> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1092365] Distutils needs a way *not* to install files
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue1092365> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1635363] Add command line help to windows unistall binary
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue1635363> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1011113] Make “install” find the build_base directory
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue103> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11213] distutils2 test issue
Alexis Metaireau added the comment: yeah, thanks for that ! -- ___ Python tracker <http://bugs.python.org/issue11213> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11219] Produce a warning when the license is specified in both the License and Classifier metadata fields
Alexis Metaireau added the comment: Hi, I was more thinking about something like: if the license is specified in the "License" metadata, then check that it's not a well known license (which can and must be provided by the classifiers instead). At the end, the code you've wrote is useful, but not complete. Additionally, it seems that your patch make check complaining if you just have *defined* classifiers and license (even if the license is not provided in the classifiers: it complains if there is both defined, regardless what is defined). It should check instead if the classifier field contain the same thing than the license field. -- ___ Python tracker <http://bugs.python.org/issue11219> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11219] Produce a warning when the license is specified in both the License and Classifier metadata fields
Alexis Metaireau added the comment: That's almost what the PEP says, or at least what I understand of it. The platform and license fields should be used only if no matching classifier exists for them. -- ___ Python tracker <http://bugs.python.org/issue11219> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14317] index.simple module lacking in distutils2
Changes by Alexis Metaireau : -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue14317> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14317] index.simple module lacking in distutils2
Alexis Metaireau added the comment: The APIs of distutils2 have changed. the "index" module is now named "pypi". So, doing something like:: >>> from distutils2.pypi.simple import Crawler should work. -- ___ Python tracker <http://bugs.python.org/issue14317> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11880] add a {dist-info} category to distutils2
Alexis Metaireau added the comment: Hey, is there any news on this bug? Berker? -- ___ Python tracker <http://bugs.python.org/issue11880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14294] Requirements are not properly copied into metatdata of dist-info
Alexis Metaireau added the comment: Thanks for reporting this Preston, Could you be a bit more precise on this one? What is the input you are giving (in the dist-info) and what is not being done? (what's the expected output and what's what you have as a result of running util.egginfo_to_distinfo) Éric, I'm not sure #11880 is a dependency of this one, could you expand on this? -- ___ Python tracker <http://bugs.python.org/issue14294> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5302] Allow package_data specs/globs to match directories
Alexis Metaireau added the comment: Agreed on this one. That would avoid to have a new syntax for this case, which seems to be very common. -- ___ Python tracker <http://bugs.python.org/issue5302> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14319] cleanup index switching mechanism on packaging.pypi
New submission from Alexis Metaireau : I need to do some general cleanup on packaging/d2, and especially on this bit. Currently, the implementation is way too complicated for what it does. -- assignee: alexis components: Distutils2 messages: 155903 nosy: alexis, tarek priority: normal severity: normal status: open title: cleanup index switching mechanism on packaging.pypi type: enhancement ___ Python tracker <http://bugs.python.org/issue14319> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14279] packaging.pypi should support flat directories of distributions
Alexis Metaireau added the comment: It is supposed to work already, but I'm not sure this is tested or complete. I'll have a closer look on this. +1 on the general idea. -- assignee: eric.araujo -> alexis ___ Python tracker <http://bugs.python.org/issue14279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14280] packaging.pypi should not require checksums
Alexis Metaireau added the comment: If no MD5 checksum is present on the crawled simple index, then we don't have to check them. This means we introduce a potential security hole here (md5 checksums were added for a reason). What could be done is to explicitely don't check them if asked so. For instance using a --no-checksum flag when running pysetup, or passing a no_checksum argument when using the crawler. Would that work for you? Éric, this is a different issue than the one you pointed out in the sence that one is for local files and the other is for remote indexes. (Of course, local files, will not need checksums as well). -- ___ Python tracker <http://bugs.python.org/issue14280> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14275] pysetup create doesn't handle install requirements
Changes by Alexis Metaireau : -- dependencies: +Requirements are not properly copied into metatdata of dist-info ___ Python tracker <http://bugs.python.org/issue14275> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14275] pysetup create doesn't handle install requirements
Changes by Alexis Metaireau : -- dependencies: -Requirements are not properly copied into metatdata of dist-info ___ Python tracker <http://bugs.python.org/issue14275> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14275] pysetup create doesn't handle install requirements
Alexis Metaireau added the comment: Thanks for reporting this, Jan-Jaap, I've marked this issue as easy, it's mostly a matter of looking at the passed parameter and outputing the list in the generated file, respecting the PEP 345 format (http://www.python.org/dev/peps/pep-0345/#requires-dist-multiple-use) Do you want to work on this one? -- keywords: +easy ___ Python tracker <http://bugs.python.org/issue14275> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14280] packaging.pypi should not require checksums
Alexis Metaireau added the comment: Right, I'll go for this then. -- ___ Python tracker <http://bugs.python.org/issue14280> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14279] packaging.pypi should support flat directories of distributions
Alexis Metaireau added the comment: Oh, thanks for clarifying this. I'll have a look at what the blockers are on this. I'm wondering if "local files" can be considered a simple index or not. If not, we can add another PyPI reader, which works with local files. -- ___ Python tracker <http://bugs.python.org/issue14279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14356] Distutils2 ignores site-local configuration
Alexis Metaireau added the comment: The supposed way to work, for OS packagers, is to ship this sysconfig.cfg thing. I'm not sure we should rely on a customized site-local configuration, without defining any standard way of doing this (IOW: what are we looking for in the site-local config?) Also, I would add that this seem to be a compatibility thing, maybe could we add a fallback to site-local if no sysconfig is found? -- ___ Python tracker <http://bugs.python.org/issue14356> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14915] pysetup may leave a package in a half-installed state
Alexis Metaireau added the comment: Oh, a potential way to avoid this would be to check that the metadata have the python 3 trove classifier in it. We could also add a way to force the installation even if the right classifier is not present with a special flag passed to the command line. Does this sounds like an acceptable change to you? -- ___ Python tracker <http://bugs.python.org/issue14915> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14946] packaging’s pysetup script should be named differently than distutils2’s pysetup
Alexis Metaireau added the comment: Good catch, One solution would be to have the pysetup script name suffixed by the version of python is comes with. For instance, for python 3.3 it would be "pysetup3.3" (that's how it is atm). This means that "pysetup" would point to "pysetup3.3" after a fresh python install, but distutils2 could change this and propose a different version of pysetup. The 3.3 version would still be available but under "pysetup3.3". -- ___ Python tracker <http://bugs.python.org/issue14946> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14948] setup.cfg - rename home_page to homepage
Alexis Metaireau added the comment: While I kind of agree with you, this field is proposed by the PEP 345 and had been approved as it is. It seems probably better to stick with what's defined there mainly because any change to the PEP is a heavy process and we won't have time to go trough it before the 3.3 release. (See http://www.python.org/dev/peps/pep-0345/#home-page-optional) -- ___ Python tracker <http://bugs.python.org/issue14948> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14949] Documentation should state clearly the differences between "pysetup run install_dist" and "pysetup install"
New submission from Alexis Metaireau : The packaging tutorial currently talks about "pysetup run install_dist" and "pysetup install" which aren't doing the same thing: one fetches the dependencies while the other doesn't. This should be stated clearly. -- assignee: eric.araujo components: Distutils2 keywords: easy messages: 161867 nosy: alexis, eric.araujo, tarek priority: normal severity: normal status: open title: Documentation should state clearly the differences between "pysetup run install_dist" and "pysetup install" versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue14949> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14950] packaging.install does not have a clear API.
New submission from Alexis Metaireau : The "packaging.install" module doesn't have a clear API defined and it's doing a lot of indirections between all the functions to get metadata, fetch the dependencies and install what's need to be installed. We might be able to come with a better solution for the API we expose there, and to allow easier maintenance. I'll go ahead this week and propose a change to this module which hopefully will make things clearer. -- assignee: alexis components: Distutils2 messages: 161868 nosy: alexis, tarek priority: normal severity: normal status: open title: packaging.install does not have a clear API. type: enhancement versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue14950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12355] Crawler doesn't follow redirection
Alexis Metaireau added the comment: Did someone changed anything in the codebase regarding this (or did it solved itself magically?) -- ___ Python tracker <http://bugs.python.org/issue12355> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14949] Documentation should state clearly the differences between "pysetup run install_dist" and "pysetup install"
Alexis Metaireau added the comment: That would be helpful yep. I can add this in the docs if you've not done it already. -- ___ Python tracker <http://bugs.python.org/issue14949> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13160] Rename install_dist to install
Alexis Metaireau added the comment: I'm +1 on this. Having an "install" command, on a distribution, makes more sense than having an "install_dist" one, because of course the object is a distribution! -- ___ Python tracker <http://bugs.python.org/issue13160> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13160] Rename install_dist to install
Changes by Alexis Metaireau : -- stage: -> needs patch ___ Python tracker <http://bugs.python.org/issue13160> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12779] Update packaging documentation
Alexis Metaireau added the comment: I think it could be helpful to have this work at least somewhere so we can work on top of it. For instance if someone wants to do changes in the documentation, then only thing it would do now would be to cause potential merge conflicts. I'm okay to have several commits for this, as it would allow us to work on the documentation with more than one person (theoretically at least). Plus I really want to see those changes! -- ___ Python tracker <http://bugs.python.org/issue12779> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14899] Naming conventions and guidelines for packages and namespace packages
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue14899> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14974] rename packaging.pypi to packaging.index
New submission from Alexis Metaireau : PyPI is the name of a particular index, whereas "index" is a generic term. So ISTM that it would be better to use the latter, semantically-wise. -- assignee: alexis components: Distutils2 messages: 162027 nosy: alexis, tarek priority: normal severity: normal stage: needs patch status: open title: rename packaging.pypi to packaging.index type: enhancement versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue14974> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14974] rename packaging.pypi to packaging.index
Alexis Metaireau added the comment: We are all calling these indexes quite everywhere. We are talking about a Python Package Index and even the mirroring infrastructure is talking about indexes. Because that's under the "packaging" namespace, it's kind of obvious that this deals with indexes "like PyPI". Of course, we also have the documentation which is a good starting point to make people realize what this is about; but I really don't think naming this "index" will be a blocker for anyone. -- ___ Python tracker <http://bugs.python.org/issue14974> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14974] rename packaging.pypi to packaging.index
Alexis Metaireau added the comment: The problem is that PyPI isn't a good name since it's the name of ONE index. Westley, do you have any other idea? Otherwise, I think we should stick to "index", which is a good name for something that's named "index" quite everywhere already. Especially because it's living under the "packaging" namespace. -- ___ Python tracker <http://bugs.python.org/issue14974> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12354] packaging.pypi.simple docs use both client and crawler name, which might be confusing
Alexis Metaireau added the comment:
> Alexis, you introduced the client/crawler naming after reading some book;
> what do you think now?
Making the distinction between a crawler and a client is probably not a
good idea since it introduces two concepts instead of one simple one.
We have indexes and different ways to access them: What about having an
"XMLRPCClient" and a "SimpleClient"?
In addition, having a simpler API, something like
packaging.indexes.get_client('simple' OR 'xmlrpc') can be useful, but
that's a different issue.
--
___
Python tracker
<http://bugs.python.org/issue12354>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14950] Make packaging.install API less confusing and more extensible
Alexis Metaireau added the comment: Attaching a work in progress file which intend to replace the current install.py file. The implementation isn't finished yet but the overall design is here. It comes with four classes: - Installer which manages the overall installation procedure. It shares a distribution cache with the dependency handler so distributions are not downloaded / extracted multiple times. The installer is able to install / remove single distributions OR distributions with their dependency tree. - DependencyHandler which takes care about getting the dependencies from either the metadata stored in the indexes or inside the distirbutions. - The DistributionCache class is just a store containing the location of the distributions that had been extracted/downloaded. It provides methods to ease the work with them (so any external user don't need to care about the state of the distribution when requesting it). - DirectoryMover provides a way to deal with moving/deleting operations with a commit/rollback API. The goal is to simplify a lot the current API and to provide a reusable tool for other installers. why not putting this in shutil at some point. This file is provided here mostly for feedback, but the work is not finished yet. -- Added file: http://bugs.python.org/file25831/install.py ___ Python tracker <http://bugs.python.org/issue14950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3754] cross-compilation support for python build
Changes by Alexis Metaireau : -- nosy: -alexis ___ Python tracker <http://bugs.python.org/issue3754> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1596321] KeyError at exit after 'import threading' in other thread
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue1596321> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8190] Add a PyPI XML-RPC client module
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue8190> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4908] Implement PEP 376
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue4908> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
