From jcrmatos at gmail.com Fri Oct 7 19:05:10 2016 From: jcrmatos at gmail.com (=?UTF-8?Q?Jo=C3=A3o_Matos?=) Date: Fri, 7 Oct 2016 16:05:10 -0700 (PDT) Subject: [Distutils] pip enhancements: check for dependent packages before uninstalling and store installation date to allow listing by it Message-ID: <1f8cb594-adc0-487b-8ce3-a9aa54938cc8@googlegroups.com> Hello, I believe it would be helpful if pip checked if there are any dependent packages before uninstalling a package. If there were, it should: 1. Warn the user by listing the dependent packages; 2. Require a specific option, eg. --alldeps to uninstall all dependent packages before uninstalling the specified package; 3. Require a specific option, eg. --force to continue with the uninstall w/o uninstalling the dependent packages (which could be dangerous, but it's the current behaviour and may be useful in specific situations). This is similar to what happens with package managers in Linux. This should also work on venvs. By storing the installation date of all packages, it should allow the list command to be ordered by it. Best regards, JM -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Mon Oct 10 10:41:39 2016 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 10 Oct 2016 15:41:39 +0100 Subject: [Distutils] [Python-Dev] pythonhosted.org upload no longer works In-Reply-To: References: Message-ID: On 10 October 2016 at 14:34, Giampaolo Rodola' wrote: > This is what I've bumped into just now: > > python setup.py upload_sphinx --upload-dir=docs/_build/html > running upload_sphinx > Submitting documentation to https://upload.pypi.org/legacy/ > Upload failed (410): Uploading documentation is no longer supported, we > recommend using https://readthedocs.org/. > > Personally I prefer pythonhosted over readthedocs as I can provide the same > style as official Python's doc (see https://pythonhosted.org/psutil/) and, > most importantly, because I can automatize doc upload just by running "make > doc-upload". > Is there a reason upload functionality has been disabled? > Is pythonhosted.org going to be dismissed or something? This was discussed on distutils-sig back in May 2015. The thread starts here: https://mail.python.org/pipermail/distutils-sig/2015-May/026327.html. One of the actions in the final proposal (https://mail.python.org/pipermail/distutils-sig/2015-May/026381.html) included a step to contact projects that were using pythonhosted.org. Did you not get any contact? It might be worth picking this up on distutils-sig, as that's where the original discussion occurred. I've copied this reply to there, and suggest followups go to that list. Paul From g.rodola at gmail.com Mon Oct 10 11:17:23 2016 From: g.rodola at gmail.com (Giampaolo Rodola') Date: Mon, 10 Oct 2016 17:17:23 +0200 Subject: [Distutils] [Python-Dev] pythonhosted.org upload no longer works In-Reply-To: References: Message-ID: Thanks Paul, no I wasn't aware of that, and I will subscribe to distutils-sig from now on. I don't remember ever receiving a warrant about this decision but it's entirely possible I may have forgot. =) So long story short is that I will have to move the doc on readthedocs, correct? Does pythonhosted provide an automatic redirect or I'll have to upload a static page which states the doc has been moved? On Mon, Oct 10, 2016 at 4:41 PM, Paul Moore wrote: > On 10 October 2016 at 14:34, Giampaolo Rodola' wrote: > > This is what I've bumped into just now: > > > > python setup.py upload_sphinx --upload-dir=docs/_build/html > > running upload_sphinx > > Submitting documentation to https://upload.pypi.org/legacy/ > > Upload failed (410): Uploading documentation is no longer supported, we > > recommend using https://readthedocs.org/. > > > > Personally I prefer pythonhosted over readthedocs as I can provide the > same > > style as official Python's doc (see https://pythonhosted.org/psutil/) > and, > > most importantly, because I can automatize doc upload just by running > "make > > doc-upload". > > Is there a reason upload functionality has been disabled? > > Is pythonhosted.org going to be dismissed or something? > > This was discussed on distutils-sig back in May 2015. The thread > starts here: https://mail.python.org/pipermail/distutils-sig/2015- > May/026327.html. > One of the actions in the final proposal > (https://mail.python.org/pipermail/distutils-sig/2015-May/026381.html) > included a step to contact projects that were using pythonhosted.org. > Did you not get any contact? > > It might be worth picking this up on distutils-sig, as that's where > the original discussion occurred. I've copied this reply to there, and > suggest followups go to that list. > > Paul > -- Giampaolo - http://grodola.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Mon Oct 10 12:06:37 2016 From: donald at stufft.io (Donald Stufft) Date: Mon, 10 Oct 2016 12:06:37 -0400 Subject: [Distutils] [Python-Dev] pythonhosted.org upload no longer works In-Reply-To: References: Message-ID: <3E64EF6B-3F35-4BFB-BADF-EA7743A560DD@stufft.io> You?re using the new PyPI (either by getting a new default from a new version of Python or Twine OR explicitly switching to it yourself) which has this disabled. You can still upload to legacy PyPI by switching the default back. That will restore the ability to upload docs to pythonhosted.org. We do plan on adding the ability to provide an automatic redirect to the new PyPI, but it?s not there yet. > On Oct 10, 2016, at 11:17 AM, Giampaolo Rodola' wrote: > > Thanks Paul, > no I wasn't aware of that, and I will subscribe to distutils-sig from now on. > I don't remember ever receiving a warrant about this decision but it's entirely possible I may have forgot. =) > So long story short is that I will have to move the doc on readthedocs, correct? > Does pythonhosted provide an automatic redirect or I'll have to upload a static page which states the doc has been moved? > > On Mon, Oct 10, 2016 at 4:41 PM, Paul Moore > wrote: > On 10 October 2016 at 14:34, Giampaolo Rodola' > wrote: > > This is what I've bumped into just now: > > > > python setup.py upload_sphinx --upload-dir=docs/_build/html > > running upload_sphinx > > Submitting documentation to https://upload.pypi.org/legacy/ > > Upload failed (410): Uploading documentation is no longer supported, we > > recommend using https://readthedocs.org/ . > > > > Personally I prefer pythonhosted over readthedocs as I can provide the same > > style as official Python's doc (see https://pythonhosted.org/psutil/ ) and, > > most importantly, because I can automatize doc upload just by running "make > > doc-upload". > > Is there a reason upload functionality has been disabled? > > Is pythonhosted.org going to be dismissed or something? > > This was discussed on distutils-sig back in May 2015. The thread > starts here: https://mail.python.org/pipermail/distutils-sig/2015-May/026327.html . > One of the actions in the final proposal > (https://mail.python.org/pipermail/distutils-sig/2015-May/026381.html ) > included a step to contact projects that were using pythonhosted.org . > Did you not get any contact? > > It might be worth picking this up on distutils-sig, as that's where > the original discussion occurred. I've copied this reply to there, and > suggest followups go to that list. > > Paul > > > > -- > Giampaolo - http://grodola.blogspot.com > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > https://mail.python.org/mailman/listinfo/distutils-sig ? Donald Stufft -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Mon Oct 10 12:27:02 2016 From: guido at python.org (Guido van Rossum) Date: Mon, 10 Oct 2016 09:27:02 -0700 Subject: [Distutils] [Python-Dev] pythonhosted.org upload no longer works In-Reply-To: <3E64EF6B-3F35-4BFB-BADF-EA7743A560DD@stufft.io> References: <3E64EF6B-3F35-4BFB-BADF-EA7743A560DD@stufft.io> Message-ID: Honestly I like readthedocs a lot, and I actually *don't* like docs that look too much like the standard Python docs -- it should be clear to readers (subliminally, through page style, not just be parsing the URL) that they're reading third party docs. On Mon, Oct 10, 2016 at 9:06 AM, Donald Stufft wrote: > You?re using the new PyPI (either by getting a new default from a new > version of Python or Twine OR explicitly switching to it yourself) which has > this disabled. You can still upload to legacy PyPI by switching the default > back. That will restore the ability to upload docs to pythonhosted.org. > > We do plan on adding the ability to provide an automatic redirect to the new > PyPI, but it?s not there yet. > > On Oct 10, 2016, at 11:17 AM, Giampaolo Rodola' wrote: > > Thanks Paul, > no I wasn't aware of that, and I will subscribe to distutils-sig from now > on. > I don't remember ever receiving a warrant about this decision but it's > entirely possible I may have forgot. =) > So long story short is that I will have to move the doc on readthedocs, > correct? > Does pythonhosted provide an automatic redirect or I'll have to upload a > static page which states the doc has been moved? > > On Mon, Oct 10, 2016 at 4:41 PM, Paul Moore wrote: >> >> On 10 October 2016 at 14:34, Giampaolo Rodola' wrote: >> > This is what I've bumped into just now: >> > >> > python setup.py upload_sphinx --upload-dir=docs/_build/html >> > running upload_sphinx >> > Submitting documentation to https://upload.pypi.org/legacy/ >> > Upload failed (410): Uploading documentation is no longer supported, we >> > recommend using https://readthedocs.org/. >> > >> > Personally I prefer pythonhosted over readthedocs as I can provide the >> > same >> > style as official Python's doc (see https://pythonhosted.org/psutil/) >> > and, >> > most importantly, because I can automatize doc upload just by running >> > "make >> > doc-upload". >> > Is there a reason upload functionality has been disabled? >> > Is pythonhosted.org going to be dismissed or something? >> >> This was discussed on distutils-sig back in May 2015. The thread >> starts here: >> https://mail.python.org/pipermail/distutils-sig/2015-May/026327.html. >> One of the actions in the final proposal >> (https://mail.python.org/pipermail/distutils-sig/2015-May/026381.html) >> included a step to contact projects that were using pythonhosted.org. >> Did you not get any contact? >> >> It might be worth picking this up on distutils-sig, as that's where >> the original discussion occurred. I've copied this reply to there, and >> suggest followups go to that list. >> >> Paul > > > > > -- > Giampaolo - http://grodola.blogspot.com > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > https://mail.python.org/mailman/listinfo/distutils-sig > > > > ? > Donald Stufft > > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) From tritium-list at sdamon.com Mon Oct 10 23:16:33 2016 From: tritium-list at sdamon.com (tritium-list at sdamon.com) Date: Mon, 10 Oct 2016 23:16:33 -0400 Subject: [Distutils] [Python-Dev] pythonhosted.org upload no longer works In-Reply-To: References: <3E64EF6B-3F35-4BFB-BADF-EA7743A560DD@stufft.io> Message-ID: <0a6601d2236d$de6f28c0$9b4d7a40$@hotmail.com> > -----Original Message----- > From: Distutils-SIG [mailto:distutils-sig-bounces+tritium- > list=sdamon.com at python.org] On Behalf Of Guido van Rossum > Sent: Monday, October 10, 2016 12:27 PM > To: Donald Stufft > Cc: Distutils ; Giampaolo Rodola' > ; python-dev > Subject: Re: [Distutils] [Python-Dev] pythonhosted.org upload no longer > works > > Honestly I like readthedocs a lot, and I actually *don't* like docs > that look too much like the standard Python docs -- it should be clear > to readers (subliminally, through page style, not just be parsing the > URL) that they're reading third party docs. > That?s quite tangential to pythonhosted.org hosting documentation... But that is a consequence of the theme used by docs.python.org/2/ using the default sphinx theme. That problem was already solved for python3 docs - they don?t use the default theme. I really don?t see how this is related at all to the uploading of docs to pythonhosted.org. From guido at python.org Tue Oct 11 00:03:11 2016 From: guido at python.org (Guido van Rossum) Date: Mon, 10 Oct 2016 21:03:11 -0700 Subject: [Distutils] [Python-Dev] pythonhosted.org upload no longer works In-Reply-To: <0a6601d2236d$de6f28c0$9b4d7a40$@hotmail.com> References: <3E64EF6B-3F35-4BFB-BADF-EA7743A560DD@stufft.io> <0a6601d2236d$de6f28c0$9b4d7a40$@hotmail.com> Message-ID: I only mentioned it because the OP mentioned the theme as one of his reasons to prefer one over the other. On Mon, Oct 10, 2016 at 8:16 PM, wrote: > > >> -----Original Message----- >> From: Distutils-SIG [mailto:distutils-sig-bounces+tritium- >> list=sdamon.com at python.org] On Behalf Of Guido van Rossum >> Sent: Monday, October 10, 2016 12:27 PM >> To: Donald Stufft >> Cc: Distutils ; Giampaolo Rodola' >> ; python-dev >> Subject: Re: [Distutils] [Python-Dev] pythonhosted.org upload no longer >> works >> >> Honestly I like readthedocs a lot, and I actually *don't* like docs >> that look too much like the standard Python docs -- it should be clear >> to readers (subliminally, through page style, not just be parsing the >> URL) that they're reading third party docs. >> > > That?s quite tangential to pythonhosted.org hosting documentation... But that is a consequence of the theme used by docs.python.org/2/ using the default sphinx theme. That problem was already solved for python3 docs - they don?t use the default theme. I really don?t see how this is related at all to the uploading of docs to pythonhosted.org. > -- --Guido van Rossum (python.org/~guido) From robin at reportlab.com Wed Oct 12 07:18:15 2016 From: robin at reportlab.com (Robin Becker) Date: Wed, 12 Oct 2016 12:18:15 +0100 Subject: [Distutils] 3.6.0b2 on windows Message-ID: <7a907b92-04dd-32b7-005b-cba54e0f29ef@chamonix.reportlab.co.uk> I have a question regarding an error message I see when building an extension for windows using the 3.6.0b2 release > C:\ux\XB33\py36_x86\lib\site-packages\wheel\pep425tags.py:77: RuntimeWarning: Config variable 'Py_DEBUG' is unset, Pytho > n ABI tag may be incorrect > warn=(impl == 'cp')): > C:\ux\XB33\py36_x86\lib\site-packages\wheel\pep425tags.py:81: RuntimeWarning: Config variable 'WITH_PYMALLOC' is unset, > Python ABI tag may be incorrect > warn=(impl == 'cp')): is this something I need to worry about? -- Robin Becker From robin at reportlab.com Wed Oct 12 10:05:34 2016 From: robin at reportlab.com (Robin Becker) Date: Wed, 12 Oct 2016 15:05:34 +0100 Subject: [Distutils] manylinux vs 3.6.0 Message-ID: <1a9cc317-7c7d-720a-dc0f-5a315227d1fd@chamonix.reportlab.co.uk> Any manylinux experts here? I tried to upgrade the docker used to build my linux packages, but I failed to get a build of python 3.6.0b2 1) I fixed a missing down load for openssl -OPENSSL_ROOT=openssl-1.0.2h -OPENSSL_HASH=1d4007e53aad94a5b2002fe045ee7bb0b3d98f1a47f8b2bc851dcd1c74332919 +OPENSSL_ROOT=openssl-1.0.2j +OPENSSL_HASH=e7aff292be21c259c6af26469c7a9b3ba26e9abaaffd325e3dccc9785256c431 2) I fixed the way the download of python source is done; seems the folder is always the numeric part of the python version and the a0 a1 b2 etc etc must be removed. - wget -q $PYTHON_DOWNLOAD_URL/$py_ver/Python-$py_ver.tgz + wget -q $PYTHON_DOWNLOAD_URL/${py_ver%[a-z][0-9]}/Python-$py_ver.tgz 3) The build of 3.6.0b2 started OK in the container, but failed with this message > + ./configure --prefix=/opt/_internal/cpython-3.6.0b2 --disable-shared > configure: WARNING: linux/random.h: present but cannot be compiled > configure: WARNING: linux/random.h: check for missing prerequisite headers? > configure: WARNING: linux/random.h: see the Autoconf documentation > configure: WARNING: linux/random.h: section "Present But Cannot Be Compiled" > configure: WARNING: linux/random.h: proceeding with the compiler's result > configure: WARNING: ## --------------------------------------- ## > configure: WARNING: ## Report this to https://bugs.python.org/ ## > configure: WARNING: ## --------------------------------------- ## > + make -j2 > Python/dtrace_stubs.o: In function `PyDTrace_LINE': > /Python-3.6.0b2/./Include/pydtrace.h:28: multiple definition of `PyDTrace_LINE' > Python/ceval.o:/Python-3.6.0b2/./Include/pydtrace.h:28: first defined here > Python/dtrace_stubs.o: In function `PyDTrace_FUNCTION_ENTRY': ...... > Modules/gcmodule.o: In function `PyDTrace_INSTANCE_DELETE_START_ENABLED': > /Python-3.6.0b2/./Include/pydtrace.h:45: multiple definition of `PyDTrace_INSTANCE_DELETE_START_ENABLED' > Python/ceval.o:/Python-3.6.0b2/./Include/pydtrace.h:45: first defined here > Modules/gcmodule.o: In function `PyDTrace_INSTANCE_DELETE_DONE_ENABLED': > /Python-3.6.0b2/./Include/pydtrace.h:46: multiple definition of `PyDTrace_INSTANCE_DELETE_DONE_ENABLED' > Python/ceval.o:/Python-3.6.0b2/./Include/pydtrace.h:46: first defined here > collect2: error: ld returned 1 exit status > make: *** [Programs/_freeze_importlib] Error 1 is the pydtrace stuff something new in the beta? I searched and found this issue https://bugs.python.org/issue28092 which seems related as it's the same centos version used in the dockerfile. As I understand it this means the new sources contain code which prevents compilation in the manylinux environment. -- Robin Becker From njs at pobox.com Wed Oct 12 17:09:44 2016 From: njs at pobox.com (Nathaniel Smith) Date: Wed, 12 Oct 2016 14:09:44 -0700 Subject: [Distutils] manylinux vs 3.6.0 In-Reply-To: <1a9cc317-7c7d-720a-dc0f-5a315227d1fd@chamonix.reportlab.co.uk> References: <1a9cc317-7c7d-720a-dc0f-5a315227d1fd@chamonix.reportlab.co.uk> Message-ID: On Wed, Oct 12, 2016 at 7:05 AM, Robin Becker wrote: > Any manylinux experts here? > > I tried to upgrade the docker used to build my linux packages, but I failed > to get a build of python 3.6.0b2 > > 1) I fixed a missing down load for openssl > -OPENSSL_ROOT=openssl-1.0.2h > -OPENSSL_HASH=1d4007e53aad94a5b2002fe045ee7bb0b3d98f1a47f8b2bc851dcd1c74332919 > +OPENSSL_ROOT=openssl-1.0.2j > +OPENSSL_HASH=e7aff292be21c259c6af26469c7a9b3ba26e9abaaffd325e3dccc9785256c431 If you could submit a quick PR for this to the manylinux repo then that'd be helpful. [...] >> Python/dtrace_stubs.o: In function `PyDTrace_LINE': >> /Python-3.6.0b2/./Include/pydtrace.h:28: multiple definition of >> `PyDTrace_LINE' >> Python/ceval.o:/Python-3.6.0b2/./Include/pydtrace.h:28: first defined here >> Python/dtrace_stubs.o: In function `PyDTrace_FUNCTION_ENTRY': [...] > is the pydtrace stuff something new in the beta? I searched and found this > issue > > https://bugs.python.org/issue28092 It's not the pydtrace stuff that's new, it's that Benjamin switched them to use some exotic C99 features to get feedback on whether those features are usable: https://bugs.python.org/issue28092#msg276164 I suspect that this will get reverted again before 3.6-final given that it does in fact cause problems... That said, I'm surprised that it's causing problems in the manylinux docker image. The default compiler on CentOS 5 is gcc 4.1, which definitely can't build 3.6.0b2. But the build scripts should be downloading and using gcc 4.8 instead, and 4.8 should be able to build 3.6.0b2. So apparently one of those shoulds is wrong. First step is probably to figure out exactly what version of gcc the Python build is using. -n -- Nathaniel J. Smith -- https://vorpus.org From steve.dower at python.org Wed Oct 12 19:32:35 2016 From: steve.dower at python.org (Steve Dower) Date: Wed, 12 Oct 2016 16:32:35 -0700 Subject: [Distutils] 3.6.0b2 on windows In-Reply-To: <7a907b92-04dd-32b7-005b-cba54e0f29ef@chamonix.reportlab.co.uk> References: <7a907b92-04dd-32b7-005b-cba54e0f29ef@chamonix.reportlab.co.uk> Message-ID: <81352b3a-d268-69c4-5110-1272537535f4@python.org> On 12Oct2016 0418, Robin Becker wrote: > I have a question regarding an error message I see when building an > extension for windows using the 3.6.0b2 release > > >> C:\ux\XB33\py36_x86\lib\site-packages\wheel\pep425tags.py:77: > RuntimeWarning: Config variable 'Py_DEBUG' is unset, Pytho >> n ABI tag may be incorrect >> warn=(impl == 'cp')): >> C:\ux\XB33\py36_x86\lib\site-packages\wheel\pep425tags.py:81: > RuntimeWarning: Config variable 'WITH_PYMALLOC' is unset, >> Python ABI tag may be incorrect >> warn=(impl == 'cp')): > > is this something I need to worry about? IIRC, these warnings have been suppressed in a newer version of pip (possibly not released yet?). They are harmless on Windows. We do need to update the bundled version of pip in 3.6, preferably before b3, to pick up the fixes to distlib and the fix for these warnings. Cheers, Steve From robin at reportlab.com Thu Oct 13 04:15:32 2016 From: robin at reportlab.com (Robin Becker) Date: Thu, 13 Oct 2016 09:15:32 +0100 Subject: [Distutils] manylinux vs 3.6.0 In-Reply-To: References: <1a9cc317-7c7d-720a-dc0f-5a315227d1fd@chamonix.reportlab.co.uk> Message-ID: On 12/10/2016 22:09, Nathaniel Smith wrote: > On Wed, Oct 12, 2016 at 7:05 AM, Robin Becker wrote: >> Any manylinux experts here? >...... >> +OPENSSL_ROOT=openssl-1.0.2j >> +OPENSSL_HASH=e7aff292be21c259c6af26469c7a9b3ba26e9abaaffd325e3dccc9785256c431 > > If you could submit a quick PR for this to the manylinux repo then > that'd be helpful. > I will attempt this, but I'm not too familiar with github as yet. I guess I have to fork etc etc. > [...] ............ > > It's not the pydtrace stuff that's new, it's that Benjamin switched > them to use some exotic C99 features to get feedback on whether those > features are usable: > https://bugs.python.org/issue28092#msg276164 > > I suspect that this will get reverted again before 3.6-final given > that it does in fact cause problems... ok, probably that should have been conditional on gcc version or something. > > That said, I'm surprised that it's causing problems in the manylinux > docker image. The default compiler on CentOS 5 is gcc 4.1, which > definitely can't build 3.6.0b2. But the build scripts should be > downloading and using gcc 4.8 instead, and 4.8 should be able to build > 3.6.0b2. So apparently one of those shoulds is wrong. First step is > probably to figure out exactly what version of gcc the Python build is > using. > I can volunteer some effort for trying to figure out what's going wrong. I did not use the deploy.sh script so perhaps my dockering was wrong somehow I did this > docker build -f Dockerfile-x86_64 -t rl/manylinux-x86_64 . > -n > -- Robin Becker From robin at reportlab.com Thu Oct 13 04:47:36 2016 From: robin at reportlab.com (Robin Becker) Date: Thu, 13 Oct 2016 09:47:36 +0100 Subject: [Distutils] manylinux vs 3.6.0 In-Reply-To: References: <1a9cc317-7c7d-720a-dc0f-5a315227d1fd@chamonix.reportlab.co.uk> Message-ID: On 12/10/2016 22:09, Nathaniel Smith wrote: ........ >> 1) I fixed a missing down load for openssl >> -OPENSSL_ROOT=openssl-1.0.2h >> -OPENSSL_HASH=1d4007e53aad94a5b2002fe045ee7bb0b3d98f1a47f8b2bc851dcd1c74332919 >> +OPENSSL_ROOT=openssl-1.0.2j >> +OPENSSL_HASH=e7aff292be21c259c6af26469c7a9b3ba26e9abaaffd325e3dccc9785256c431 > > If you could submit a quick PR for this to the manylinux repo then > that'd be helpful. .... well I created a pull request, but I hope I pulled into the right version of manylinux ie https://github.com/pypa/manylinux -- Robin Becker From robin at reportlab.com Thu Oct 13 04:58:28 2016 From: robin at reportlab.com (Robin Becker) Date: Thu, 13 Oct 2016 09:58:28 +0100 Subject: [Distutils] manylinux vs 3.6.0 In-Reply-To: References: <1a9cc317-7c7d-720a-dc0f-5a315227d1fd@chamonix.reportlab.co.uk> Message-ID: On 12/10/2016 22:09, Nathaniel Smith wrote: ......... > That said, I'm surprised that it's causing problems in the manylinux > docker image. The default compiler on CentOS 5 is gcc 4.1, which > definitely can't build 3.6.0b2. But the build scripts should be > downloading and using gcc 4.8 instead, and 4.8 should be able to build > 3.6.0b2. So apparently one of those shoulds is wrong. First step is > probably to figure out exactly what version of gcc the Python build is > using. immediately after the devtool setup the build.sh script reports the version as > ==================gcc================= > gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15) > Copyright (C) 2013 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Robin Becker From robin at reportlab.com Thu Oct 13 08:53:29 2016 From: robin at reportlab.com (Robin Becker) Date: Thu, 13 Oct 2016 13:53:29 +0100 Subject: [Distutils] manylinux vs 3.6.0 In-Reply-To: References: <1a9cc317-7c7d-720a-dc0f-5a315227d1fd@chamonix.reportlab.co.uk> Message-ID: On 12/10/2016 22:09, Nathaniel Smith wrote: > On Wed, Oct 12, 2016 at 7:05 AM, Robin Becker wrote: >> Any manylinux experts here? >> ....... > https://bugs.python.org/issue28092#msg276164 > > I suspect that this will get reverted again before 3.6-final given > that it does in fact cause problems... I prodded that issue with> >> Don't want to add too much noise, but this issue also affects the manylinux project build compiler (gcc 4.8.2). > STINNER Victor added the comment: > > Would it be possible to upgrade the "manylinux" compiler (take a more recent GCC version)? I'm not the expert here, but I though the whole point was to have a common denominator system. Is gcc part of the 'commons' or can we use any version of the compiler provided the other common denominator libs are acceptable to it? -- Robin Becker From njs at pobox.com Thu Oct 13 13:57:06 2016 From: njs at pobox.com (Nathaniel Smith) Date: Thu, 13 Oct 2016 10:57:06 -0700 Subject: [Distutils] manylinux vs 3.6.0 In-Reply-To: References: <1a9cc317-7c7d-720a-dc0f-5a315227d1fd@chamonix.reportlab.co.uk> Message-ID: On Thu, Oct 13, 2016 at 5:53 AM, Robin Becker wrote: > On 12/10/2016 22:09, Nathaniel Smith wrote: >> >> On Wed, Oct 12, 2016 at 7:05 AM, Robin Becker wrote: >>> >>> Any manylinux experts here? >>> > ....... >> >> https://bugs.python.org/issue28092#msg276164 >> >> I suspect that this will get reverted again before 3.6-final given >> that it does in fact cause problems... > > > I prodded that issue with> > > > >>> Don't want to add too much noise, but this issue also affects the >>> manylinux project build compiler (gcc 4.8.2). > > >> STINNER Victor added the comment: >> >> >> Would it be possible to upgrade the "manylinux" compiler (take a more >> recent GCC version)? > > > I'm not the expert here, but I though the whole point was to have a common > denominator system. Is gcc part of the 'commons' or can we use any version > of the compiler provided the other common denominator libs are acceptable to > it? Replied there: https://bugs.python.org/issue28092#msg278584 -- Nathaniel J. Smith -- https://vorpus.org From ben+python at benfinney.id.au Sat Oct 15 03:06:25 2016 From: ben+python at benfinney.id.au (Ben Finney) Date: Sat, 15 Oct 2016 18:06:25 +1100 Subject: [Distutils] Interrogate distribution for an entry point command path Message-ID: <85r37ijdla.fsf@benfinney.id.au> Howdy, How can a Python application discover at run-time where on the filesystem its own ?entry_points? programs are available? The Setuptools ?entry_points? are available at run-time to the distribution, via the ?pkg_resources? API for entry points . I don't see there how to interrogate for which filesystem path to invoke for a specific entry point's command. How can I reliably ask ?pkg_resources? for ?where is the entry point named ?foo? installed?? such that I get a filesystem path of a command to invoke? -- \ ?Geeks like to think that they can ignore politics. You can | `\ leave politics alone, but politics won't leave you alone.? | _o__) ?Richard M. Stallman, 2002-07-26 | Ben Finney From prometheus235 at gmail.com Sat Oct 15 09:51:39 2016 From: prometheus235 at gmail.com (Nick Timkovich) Date: Sat, 15 Oct 2016 08:51:39 -0500 Subject: [Distutils] Interrogate distribution for an entry point command path In-Reply-To: <85r37ijdla.fsf@benfinney.id.au> References: <85r37ijdla.fsf@benfinney.id.au> Message-ID: Usually that entry point is on the PATH, so it should be somewhere in os.environ['PATH'], so if you just `subprocess.run(['myentrything'])` that would fire it. If you want to call that entry point from your code, the clean way (same environment/version, and especially if you don't need to bother multiprocessing it) would be to import the corresponding entry point function & call that. I might not be answering your question directly, but hopefully there's a workaround there. What's your use-case for grabbing the exec path? On Sat, Oct 15, 2016 at 2:06 AM, Ben Finney wrote: > Howdy, > > How can a Python application discover at run-time where on the > filesystem its own ?entry_points? programs are available? > > The Setuptools ?entry_points? are available at run-time to the > distribution, via the ?pkg_resources? API for entry points > resources.html#entry-points>. > > I don't see there how to interrogate for which filesystem path to invoke > for a specific entry point's command. > > How can I reliably ask ?pkg_resources? for ?where is the entry point > named ?foo? installed?? such that I get a filesystem path of a command > to invoke? > > -- > \ ?Geeks like to think that they can ignore politics. You can | > `\ leave politics alone, but politics won't leave you alone.? | > _o__) ?Richard M. Stallman, 2002-07-26 | > Ben Finney > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > https://mail.python.org/mailman/listinfo/distutils-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben+python at benfinney.id.au Sat Oct 15 13:57:28 2016 From: ben+python at benfinney.id.au (Ben Finney) Date: Sun, 16 Oct 2016 04:57:28 +1100 Subject: [Distutils] Interrogate distribution for an entry point command path References: <85r37ijdla.fsf@benfinney.id.au> Message-ID: <85mvi5jy0n.fsf@benfinney.id.au> Nick Timkovich writes: > Usually that entry point is on the PATH [?] It's not, because I'm deliberately specifying that it shouldn't be, at install time. This is an executable that is private to the application and not for general availability on the host. > If you want to call that entry point from your code, the clean way > (same environment/version, and especially if you don't need to bother > multiprocessing it) would be to import the corresponding entry point > function & call that. I'm modifying an existing application that invokes the program as a subprocess, so I'm wanting to find that program as an external command. > I might not be answering your question directly, but hopefully there's > a workaround there. What's your use-case for grabbing the exec path? Existing code assumes it is an external command on the shell PATH, but I'm changing that so that it's not on PATH. I need to make a minimal change and want to ensure that I get the right filesystem path based on what the distribution knows about itself. -- \ ?I like to fill my bathtub up with water, then turn the shower | `\ on and pretend I'm in a submarine that's been hit.? ?Steven | _o__) Wright | Ben Finney From prometheus235 at gmail.com Sat Oct 15 14:05:52 2016 From: prometheus235 at gmail.com (Nick Timkovich) Date: Sat, 15 Oct 2016 13:05:52 -0500 Subject: [Distutils] Interrogate distribution for an entry point command path In-Reply-To: <85mvi5jy0n.fsf@benfinney.id.au> References: <85r37ijdla.fsf@benfinney.id.au> <85mvi5jy0n.fsf@benfinney.id.au> Message-ID: I recently was trying to port a mix of shell & Python scripts to pure Python (https://github.com/nicktimko/autolycus), and my interim solution to get something working to test was to: 1. include the shell scripts (could also be binaries) in the package & manifest (https://github.com/nicktimko/autolycus/blob/master/MANIFEST.in#L3) 2. use pkg_resources to get where the .sh was so I could run it with subprocess. ( https://github.com/nicktimko/autolycus/blob/master/autolycus/legacy.py) Closer to what you need? On Sat, Oct 15, 2016 at 12:57 PM, Ben Finney wrote: > Nick Timkovich writes: > > > Usually that entry point is on the PATH [?] > > It's not, because I'm deliberately specifying that it shouldn't be, at > install time. This is an executable that is private to the application > and not for general availability on the host. > > > If you want to call that entry point from your code, the clean way > > (same environment/version, and especially if you don't need to bother > > multiprocessing it) would be to import the corresponding entry point > > function & call that. > > I'm modifying an existing application that invokes the program as a > subprocess, so I'm wanting to find that program as an external command. > > > I might not be answering your question directly, but hopefully there's > > a workaround there. What's your use-case for grabbing the exec path? > > Existing code assumes it is an external command on the shell PATH, but > I'm changing that so that it's not on PATH. I need to make a minimal > change and want to ensure that I get the right filesystem path based on > what the distribution knows about itself. > > -- > \ ?I like to fill my bathtub up with water, then turn the shower | > `\ on and pretend I'm in a submarine that's been hit.? ?Steven | > _o__) Wright | > Ben Finney > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > https://mail.python.org/mailman/listinfo/distutils-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prometheus235 at gmail.com Sat Oct 15 14:12:14 2016 From: prometheus235 at gmail.com (Nick Timkovich) Date: Sat, 15 Oct 2016 13:12:14 -0500 Subject: [Distutils] Interrogate distribution for an entry point command path In-Reply-To: References: <85r37ijdla.fsf@benfinney.id.au> <85mvi5jy0n.fsf@benfinney.id.au> Message-ID: The entry points aren't needed at all in that case, but I made a shim (that legacy.py) anyways to have access to the packaged shell script for testing. On Sat, Oct 15, 2016 at 1:05 PM, Nick Timkovich wrote: > I recently was trying to port a mix of shell & Python scripts to pure > Python (https://github.com/nicktimko/autolycus), and my interim solution > to get something working to test was to: > > 1. include the shell scripts (could also be binaries) in the package & > manifest (https://github.com/nicktimko/autolycus/blob/master/ > MANIFEST.in#L3) > 2. use pkg_resources to get where the .sh was so I could run it with > subprocess. (https://github.com/nicktimko/autolycus/blob/master/ > autolycus/legacy.py) > > Closer to what you need? > > On Sat, Oct 15, 2016 at 12:57 PM, Ben Finney > wrote: > >> Nick Timkovich writes: >> >> > Usually that entry point is on the PATH [?] >> >> It's not, because I'm deliberately specifying that it shouldn't be, at >> install time. This is an executable that is private to the application >> and not for general availability on the host. >> >> > If you want to call that entry point from your code, the clean way >> > (same environment/version, and especially if you don't need to bother >> > multiprocessing it) would be to import the corresponding entry point >> > function & call that. >> >> I'm modifying an existing application that invokes the program as a >> subprocess, so I'm wanting to find that program as an external command. >> >> > I might not be answering your question directly, but hopefully there's >> > a workaround there. What's your use-case for grabbing the exec path? >> >> Existing code assumes it is an external command on the shell PATH, but >> I'm changing that so that it's not on PATH. I need to make a minimal >> change and want to ensure that I get the right filesystem path based on >> what the distribution knows about itself. >> >> -- >> \ ?I like to fill my bathtub up with water, then turn the shower | >> `\ on and pretend I'm in a submarine that's been hit.? ?Steven | >> _o__) Wright | >> Ben Finney >> >> _______________________________________________ >> Distutils-SIG maillist - Distutils-SIG at python.org >> https://mail.python.org/mailman/listinfo/distutils-sig >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben+python at benfinney.id.au Sat Oct 15 14:12:16 2016 From: ben+python at benfinney.id.au (Ben Finney) Date: Sun, 16 Oct 2016 05:12:16 +1100 Subject: [Distutils] Interrogate distribution for an entry point command path References: <85r37ijdla.fsf@benfinney.id.au> <85mvi5jy0n.fsf@benfinney.id.au> Message-ID: <85h98djxbz.fsf@benfinney.id.au> Nick Timkovich writes: > 1. include the shell scripts (could also be binaries) in the package & > manifest > (https://github.com/nicktimko/autolycus/blob/master/MANIFEST.in#L3) No, I'm using ?[?] install --install-scripts=APPLICATION_SCRIPTS_PATH? at install time. > 2. use pkg_resources to get where the .sh was so I could run it with > subprocess. What I need is for ?pkg_resources? to tell me at run time where ?--install-scripts? put the scripts for this application. -- \ ?I don't accept the currently fashionable assertion that any | `\ view is automatically as worthy of respect as any equal and | _o__) opposite view.? ?Douglas Adams | Ben Finney From jaraco at jaraco.com Sat Oct 15 14:50:04 2016 From: jaraco at jaraco.com (Jason R. Coombs) Date: Sat, 15 Oct 2016 18:50:04 +0000 Subject: [Distutils] Commit 17f89f4 "Update sdist to use sdist_add_defaults forward compatibility" In-Reply-To: References: Message-ID: <18493F64-00B8-4301-A136-8E423A641860@jaraco.com> The discussion started here: https://github.com/pypa/setuptools/pull/750 Basically, I don?t understand exactly why that functionality was disabled, but I give my best guess in that ticket - mainly that I think data_files is incompatible with encapsulated installs, so I suspect it was explicitly, intentionally excluded, though I?ve found no evidence to that effect. So for now, for compatibility, I?ve explicitly excluded that functionality with a comment. I?ve also explicitly overridden _add_defaults_python to capture the overriding behavior, which while similar isn?t identical. I?m leaving it as a subsequent exercise to see if that implementation can be merged. In my conclusion in that PR, I?ve suggested we go ahead and re-enable data_files, though I suggest we also add a test capturing that expectation. > On 15 Oct, 2016, at 13:43, Brandon Casey wrote: > > Hi Jason, > > I just started looking at the setuptools repo last night to see if I > could figure out why setuptools doesn't place data_files inside an > sdist and I saw your commit 17f89f4 to teach the sdist command to use > the python 36 compatibility behavior. But it overrides > _add_defaults_data_files() which actually adds the data_files to the > filelist, and replaces it with an empty function. > > If I remove this function, so that the one from > py36compat.sdist_add_defaults is used, then it seems to work correctly > for me. But that is the extent of my testing so far. > > The doc comment for the new _add_defaults_data_files function just says: > > Don't add any data files, but why? > > I see _add_defaults_python() was also overridden and is now only > slightly different from the one in py36compat.sdist_add_defaults. It > looks like maybe you were just trying to make use of the py36compat > functions without introducing any change in behavior. Is that the > only reason that _add_defaults_python() differs from the one in > py36compat and why _add_defaults_data_files is disabled? Or do you > have some concerns about enabling this functionality? Any thoughts of > enabling it? If there's some active discussion or explanation on a > mailing list somewhere, please feel free to point me towards that. > > Thanks, > -Brandon From thomas at kluyver.me.uk Sat Oct 15 18:07:32 2016 From: thomas at kluyver.me.uk (Thomas Kluyver) Date: Sat, 15 Oct 2016 23:07:32 +0100 Subject: [Distutils] Interrogate distribution for an entry point command path In-Reply-To: <85mvi5jy0n.fsf@benfinney.id.au> References: <85r37ijdla.fsf@benfinney.id.au> <85mvi5jy0n.fsf@benfinney.id.au> Message-ID: <1476569252.92078.757114913.701AB31B@webmail.messagingengine.com> On Sat, Oct 15, 2016, at 06:57 PM, Ben Finney wrote: > I'm modifying an existing application that invokes the program as a > subprocess, so I'm wanting to find that program as an external command. If the entry point looks like: foo=foomod:main Then you can invoke it in a subprocess by running: subprocess.Popen([sys.executable, '-c', 'import foomod; foomod.main()']) This avoids the need to work out where the 'foo' script has been installed to. From ben+python at benfinney.id.au Sat Oct 15 19:38:45 2016 From: ben+python at benfinney.id.au (Ben Finney) Date: Sun, 16 Oct 2016 10:38:45 +1100 Subject: [Distutils] Interrogate distribution for an entry point command path References: <85r37ijdla.fsf@benfinney.id.au> <85mvi5jy0n.fsf@benfinney.id.au> <1476569252.92078.757114913.701AB31B@webmail.messagingengine.com> Message-ID: <85d1j1ji7u.fsf@benfinney.id.au> Thomas Kluyver writes: > If the entry point looks like: > > foo=foomod:main > > Then you can invoke it in a subprocess by running: > > subprocess.Popen([sys.executable, '-c', 'import foomod; foomod.main()']) That will invoke the program. I'll probably try that. One disadvantage there is the process won't have an informative name; instead of being named ?/foo/bar/lipsum?, it will be named ?python? which is less useful. > This avoids the need to work out where the 'foo' script has been > installed to. So, I'm still wanting to know from Setuptools itself at run time, what filesystem path Setuptools installed the command to. -- \ ?I took it easy today. I just pretty much layed around in my | `\ underwear all day. ? Got kicked out of quite a few places, | _o__) though.? ?Bug-Eyed Earl, _Red Meat_ | Ben Finney From drafnel at gmail.com Sat Oct 15 13:43:38 2016 From: drafnel at gmail.com (Brandon Casey) Date: Sat, 15 Oct 2016 10:43:38 -0700 Subject: [Distutils] Commit 17f89f4 "Update sdist to use sdist_add_defaults forward compatibility" Message-ID: Hi Jason, I just started looking at the setuptools repo last night to see if I could figure out why setuptools doesn't place data_files inside an sdist and I saw your commit 17f89f4 to teach the sdist command to use the python 36 compatibility behavior. But it overrides _add_defaults_data_files() which actually adds the data_files to the filelist, and replaces it with an empty function. If I remove this function, so that the one from py36compat.sdist_add_defaults is used, then it seems to work correctly for me. But that is the extent of my testing so far. The doc comment for the new _add_defaults_data_files function just says: Don't add any data files, but why? I see _add_defaults_python() was also overridden and is now only slightly different from the one in py36compat.sdist_add_defaults. It looks like maybe you were just trying to make use of the py36compat functions without introducing any change in behavior. Is that the only reason that _add_defaults_python() differs from the one in py36compat and why _add_defaults_data_files is disabled? Or do you have some concerns about enabling this functionality? Any thoughts of enabling it? If there's some active discussion or explanation on a mailing list somewhere, please feel free to point me towards that. Thanks, -Brandon From dholth at gmail.com Sat Oct 15 22:17:20 2016 From: dholth at gmail.com (Daniel Holth) Date: Sun, 16 Oct 2016 02:17:20 +0000 Subject: [Distutils] Interrogate distribution for an entry point command path In-Reply-To: <85d1j1ji7u.fsf@benfinney.id.au> References: <85r37ijdla.fsf@benfinney.id.au> <85mvi5jy0n.fsf@benfinney.id.au> <1476569252.92078.757114913.701AB31B@webmail.messagingengine.com> <85d1j1ji7u.fsf@benfinney.id.au> Message-ID: It does not store that information, except maybe in the manifest used for uninstall in the .*-info directory for your installed distribution. On Sat, Oct 15, 2016, 19:39 Ben Finney wrote: > Thomas Kluyver writes: > > > If the entry point looks like: > > > > foo=foomod:main > > > > Then you can invoke it in a subprocess by running: > > > > subprocess.Popen([sys.executable, '-c', 'import foomod; foomod.main()']) > > That will invoke the program. I'll probably try that. > > One disadvantage there is the process won't have an informative name; > instead of being named ?/foo/bar/lipsum?, it will be named ?python? > which is less useful. > > > This avoids the need to work out where the 'foo' script has been > > installed to. > > So, I'm still wanting to know from Setuptools itself at run time, what > filesystem path Setuptools installed the command to. > > -- > \ ?I took it easy today. I just pretty much layed around in my | > `\ underwear all day. ? Got kicked out of quite a few places, | > _o__) though.? ?Bug-Eyed Earl, _Red Meat_ | > Ben Finney > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > https://mail.python.org/mailman/listinfo/distutils-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Sun Oct 16 03:38:42 2016 From: p.f.moore at gmail.com (Paul Moore) Date: Sun, 16 Oct 2016 08:38:42 +0100 Subject: [Distutils] Interrogate distribution for an entry point command path In-Reply-To: <85d1j1ji7u.fsf@benfinney.id.au> References: <85r37ijdla.fsf@benfinney.id.au> <85mvi5jy0n.fsf@benfinney.id.au> <1476569252.92078.757114913.701AB31B@webmail.messagingengine.com> <85d1j1ji7u.fsf@benfinney.id.au> Message-ID: On 16 October 2016 at 00:38, Ben Finney wrote: >> This avoids the need to work out where the 'foo' script has been >> installed to. > > So, I'm still wanting to know from Setuptools itself at run time, what > filesystem path Setuptools installed the command to. Setuptools doesn't install the command, it just records entry point metadata. The installer (pip, presumably?) creates the wrapper. The name of the wrapper file that gets installed is technically recorded in the installed files metadata (for use by pip uninstall) but there's no information recording the link between the entry point and the file. Paul From njs at pobox.com Sun Oct 16 04:24:18 2016 From: njs at pobox.com (Nathaniel Smith) Date: Sun, 16 Oct 2016 01:24:18 -0700 Subject: [Distutils] Interrogate distribution for an entry point command path In-Reply-To: <85d1j1ji7u.fsf@benfinney.id.au> References: <85r37ijdla.fsf@benfinney.id.au> <85mvi5jy0n.fsf@benfinney.id.au> <1476569252.92078.757114913.701AB31B@webmail.messagingengine.com> <85d1j1ji7u.fsf@benfinney.id.au> Message-ID: On Sat, Oct 15, 2016 at 4:38 PM, Ben Finney wrote: > Thomas Kluyver writes: > >> If the entry point looks like: >> >> foo=foomod:main >> >> Then you can invoke it in a subprocess by running: >> >> subprocess.Popen([sys.executable, '-c', 'import foomod; foomod.main()']) > > That will invoke the program. I'll probably try that. > > One disadvantage there is the process won't have an informative name; > instead of being named ?/foo/bar/lipsum?, it will be named ?python? > which is less useful. I won't claim it's pretty to look at, but if this is a major issue then as a workaround I suppose you can consider adding a dependency on https://pypi.org/project/setproctitle/ and running [sys.executable, '-c', 'import setproctitle; setproctitle.setproctitle("foo"); import foomod; foomod.main()] -n -- Nathaniel J. Smith -- https://vorpus.org From radomir at dopieralski.pl Thu Oct 20 05:43:16 2016 From: radomir at dopieralski.pl (Radomir Dopieralski) Date: Thu, 20 Oct 2016 11:43:16 +0200 Subject: [Distutils] Trove classifiers for MicroPython? Message-ID: <20161020114316.0b587052@ghostwheel> Hello everyone, I'm not sure this is the right place to write to propose new trove classifiers for PyPi -- if it's not, what would be the right place? If this is it, then please read below. The MicroPython project is quickly growing and becoming more mature, and as that happens, the number of 3rd-party libraries for it grows. Many of those libraries get uploaded to PyPi, as you can check by searching for "micropython". MicroPython has even its own version of "pip", called "upip", that can be used to install those libraries. However, there is as of yet no way to mark that a library is written for that particular flavor of Python, as there are no trove classifiers for it. I would like to propose adding a number of classifiers to amend that situation: For the MicroPython itself: Programming Language :: Python :: Implementation :: MicroPython For the hardware it runs on: Operating System :: Baremetal Environment :: Microcontroller Environment :: Microcontroller :: PyBoard Environment :: Microcontroller :: ESP8266 Environment :: Microcontroller :: Micro:bit Environment :: Microcontroller :: WiPy Environment :: Microcontroller :: LoPy Environment :: Microcontroller :: OpenMV I'm not sure if the latter makes sense, but it would certainly be nice to be able to indicate in a machine-parseable way on which platforms the code works. What do you think? -- Radomir Dopieralski From tseaver at palladion.com Thu Oct 20 10:48:29 2016 From: tseaver at palladion.com (Tres Seaver) Date: Thu, 20 Oct 2016 10:48:29 -0400 Subject: [Distutils] Trove classifiers for MicroPython? In-Reply-To: <20161020114316.0b587052@ghostwheel> References: <20161020114316.0b587052@ghostwheel> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/20/2016 05:43 AM, Radomir Dopieralski wrote: > I'm not sure this is the right place to write to propose new trove > classifiers for PyPi -- if it's not, what would be the right place? If > this is it, then please read below. This is definitely the correct location: the former 'catalog-sig' list is retired. > The MicroPython project is quickly growing and becoming more mature, > and as that happens, the number of 3rd-party libraries for it grows. > Many of those libraries get uploaded to PyPi, as you can check by > searching for "micropython". MicroPython has even its own version of > "pip", called "upip", that can be used to install those libraries. > > However, there is as of yet no way to mark that a library is written > for that particular flavor of Python, as there are no trove > classifiers for it. I would like to propose adding a number of > classifiers to amend that situation: > > For the MicroPython itself: > > Programming Language :: Python :: Implementation :: MicroPython +1 for this one. > For the hardware it runs on: > > Operating System :: Baremetal Environment :: Microcontroller > Environment :: Microcontroller :: PyBoard Environment :: > Microcontroller :: ESP8266 Environment :: Microcontroller :: > Micro:bit Environment :: Microcontroller :: WiPy Environment :: > Microcontroller :: LoPy Environment :: Microcontroller :: OpenMV > > I'm not sure if the latter makes sense, but it would certainly be nice > to be able to indicate in a machine-parseable way on which platforms > the code works. Are there actual binary wheels being uploaded which compiled for specific boards? Or is it that the packages depend at runtime on board-specific features? Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJYCNk3AAoJEPKpaDSJE9HYsl8P/2VBfoIqIE/NU4+zxfjV4pX5 nwnrnjxjfHEGIibmdhM0wh6CouaqqhaWdmgMKu66UoZVmJFiE/WAPYmHhcC0jHSC Mk699B5+fZATywJp/NweaogpcaJiEvJEpcostD4Z15sfmzYCrrOZ4ylDSPq1+D98 ypQRhRjxjrMu9RxIOOJFOKHbvyHZ+NThAgvF7e7sDG5SVWeEPVN9ga8+F9B6JJjw 0Wgo0G/pTrTikVr/HSAbpkiQZRey4rhaN6hg5y0C4O2M/Sf4zrik0BfC8eWt23HY tIT2EFhr5NR/9JaFYWkgZmrVFf23JJezS/1N6zGVKFIaf7AsCGh1LFy8jZNYuA7P 7uNzPM+9otgPp7Vx5w/rLKQXN2MlUKAZmX1FoUz5MBL3m7RaCctYMbxOaxxjXEJy vORr1r7iOm9kw9YXIuVrtI5X9d+518IQ3Ege4JxhIhi+V90j6ht1wAXoGdLCqYNJ OqrMbayhEatzj9dWu+3P5CrzyEfe2frahdBcms+PT/uDNKXA4SJBEibHYfv16yWb Z26mx3sD3R65ceRl7wCgYy4G3rt1DTro2/LGfm2f92HHdmIHNWJI5sPcJSst9n69 1AdLZU6N/PSS3k5LRLia4GnTVfBJBxphTfywIcP81kHNLUvBvnX5bQhLnYAGL4Yj l3sj1cK2n4dhWhvDLYds =nBUj -----END PGP SIGNATURE----- From drafnel at gmail.com Fri Oct 21 00:58:36 2016 From: drafnel at gmail.com (Brandon Casey) Date: Thu, 20 Oct 2016 21:58:36 -0700 Subject: [Distutils] Commit 17f89f4 "Update sdist to use sdist_add_defaults forward compatibility" In-Reply-To: <18493F64-00B8-4301-A136-8E423A641860@jaraco.com> References: <18493F64-00B8-4301-A136-8E423A641860@jaraco.com> Message-ID: Hey Jason, Thanks for the quick reply. I wasn't able to get around to doing it this past weekend. I'll try to take a look this weekend. -Brandon On Sat, Oct 15, 2016 at 11:50 AM, Jason R. Coombs wrote: > The discussion started here: https://github.com/pypa/setuptools/pull/750 > > Basically, I don?t understand exactly why that functionality was disabled, but I give my best guess in that ticket - mainly that I think data_files is incompatible with encapsulated installs, so I suspect it was explicitly, intentionally excluded, though I?ve found no evidence to that effect. > > So for now, for compatibility, I?ve explicitly excluded that functionality with a comment. > > I?ve also explicitly overridden _add_defaults_python to capture the overriding behavior, which while similar isn?t identical. I?m leaving it as a subsequent exercise to see if that implementation can be merged. > > In my conclusion in that PR, I?ve suggested we go ahead and re-enable data_files, though I suggest we also add a test capturing that expectation. > >> On 15 Oct, 2016, at 13:43, Brandon Casey wrote: >> >> Hi Jason, >> >> I just started looking at the setuptools repo last night to see if I >> could figure out why setuptools doesn't place data_files inside an >> sdist and I saw your commit 17f89f4 to teach the sdist command to use >> the python 36 compatibility behavior. But it overrides >> _add_defaults_data_files() which actually adds the data_files to the >> filelist, and replaces it with an empty function. >> >> If I remove this function, so that the one from >> py36compat.sdist_add_defaults is used, then it seems to work correctly >> for me. But that is the extent of my testing so far. >> >> The doc comment for the new _add_defaults_data_files function just says: >> >> Don't add any data files, but why? >> >> I see _add_defaults_python() was also overridden and is now only >> slightly different from the one in py36compat.sdist_add_defaults. It >> looks like maybe you were just trying to make use of the py36compat >> functions without introducing any change in behavior. Is that the >> only reason that _add_defaults_python() differs from the one in >> py36compat and why _add_defaults_data_files is disabled? Or do you >> have some concerns about enabling this functionality? Any thoughts of >> enabling it? If there's some active discussion or explanation on a >> mailing list somewhere, please feel free to point me towards that. >> >> Thanks, >> -Brandon > From houtman.benjamin at gmail.com Sun Oct 30 12:01:02 2016 From: houtman.benjamin at gmail.com (Benjamin Houtman) Date: Sun, 30 Oct 2016 12:01:02 -0400 Subject: [Distutils] installing bagit-python from the Library of Congress GitHub Message-ID: Hello, I'm trying to install bagit-python from the LoC Github https://github.com/ LibraryOfCongress/bagit-python I have Windows 10 and I downloaded Python 2.7.12 and the most recent iteration of bag-it. According to the README file I should be able to type in "pip install bagit" to install bagit globally, but instead I get "SyntaxEror: invalid syntax." It's my understanding that pip is automatically part of 2.7.12. There are no instructions as to what to do if this happens. I should be able to get to something called bagit.py, but it's unclear what that means as I can't get any further. If you could let me know what I can do it would be much appreciated. I'm pretty new to this. Best, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Sun Oct 30 17:00:33 2016 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Sun, 30 Oct 2016 14:00:33 -0700 Subject: [Distutils] installing bagit-python from the Library of Congress GitHub In-Reply-To: References: Message-ID: Hello Benjamin, Can you pass the full error message please ? Or would the error message be something like : >>> pip install bagit File "", line 1 pip install bagit ^ SyntaxError: invalid syntax If so that's because `pip` is not a command that you should run from inside the Python shell but from within the Windows command prompt, before entering a Python REPL. You can see that I'm in the Python repl because it start with a >>>. The windows repl start (if I remember correctly) by C:\Path\To\Somewhere> . We'll not go into detail as of why this is the case that you have to use pip from outside the Python shell. Hope that make some sens. I'm unfortunately not familiar enough with windows to tell you how to access the windows command prompt. Thanks, -- M On Sun, Oct 30, 2016 at 9:01 AM, Benjamin Houtman wrote: > Hello, > I'm trying to install bagit-python from the LoC Github > https://github.com/LibraryOfCongress/bagit-python > I have Windows 10 and I downloaded Python 2.7.12 and the most recent > iteration of bag-it. According to the README file I should be able to type > in "pip install bagit" to install bagit globally, but instead I get > "SyntaxEror: invalid syntax." It's my understanding that pip is > automatically part of 2.7.12. > There are no instructions as to what to do if this happens. I should be able > to get to something called bagit.py, but it's unclear what that means as I > can't get any further. If you could let me know what I can do it would be > much appreciated. I'm pretty new to this. > Best, > Ben > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > https://mail.python.org/mailman/listinfo/distutils-sig > From alex.gronholm at nextday.fi Sun Oct 30 17:00:36 2016 From: alex.gronholm at nextday.fi (=?UTF-8?Q?Alex_Gr=c3=b6nholm?=) Date: Sun, 30 Oct 2016 23:00:36 +0200 Subject: [Distutils] installing bagit-python from the Library of Congress GitHub In-Reply-To: References: Message-ID: Pip is a command line tool. Are you trying to use it from the interactive Python interpreter instead? 30.10.2016, 18:01, Benjamin Houtman kirjoitti: > Hello, > I'm trying to install bagit-python from the LoC Github > https://github.com/LibraryOfCongress/bagit-python > > I have Windows 10 and I downloaded Python 2.7.12 and the most recent > iteration of bag-it. According to the README file I should be able to > type in "pip install bagit" to install bagit globally, but instead I > get "SyntaxEror: invalid syntax." It's my understanding that pip is > automatically part of 2.7.12. > There are no instructions as to what to do if this happens. I should > be able to get to something called bagit.py, but it's unclear what > that means as I can't get any further. If you could let me know what I > can do it would be much appreciated. I'm pretty new to this. > Best, > Ben > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > https://mail.python.org/mailman/listinfo/distutils-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: From radomir at dopieralski.pl Sun Oct 30 18:17:33 2016 From: radomir at dopieralski.pl (Radomir Dopieralski) Date: Sun, 30 Oct 2016 23:17:33 +0100 Subject: [Distutils] Trove classifiers for MicroPython? Message-ID: <20161030231733.5ae71bb0@ghostwheel> I'm sorry for a delay, but I'm not subscribed to this list, and I didn't receive the reply to my address. Thu Oct 20 10:48:29 EDT 2016, Tres Seaver: >On 10/20/2016 05:43 AM, Radomir Dopieralski wrote: [...] >> For the hardware it runs on: >> >> Operating System :: Baremetal Environment :: Microcontroller >> Environment :: Microcontroller :: PyBoard Environment :: >> Microcontroller :: ESP8266 Environment :: Microcontroller :: >> Micro:bit Environment :: Microcontroller :: WiPy Environment :: >> Microcontroller :: LoPy Environment :: Microcontroller :: OpenMV >> >> I'm not sure if the latter makes sense, but it would certainly be nice >> to be able to indicate in a machine-parseable way on which platforms >> the code works. > >Are there actual binary wheels being uploaded which compiled for specific >boards? Or is it that the packages depend at runtime on board-specific >features? There is no wheel format for the MicroPython, at this moment. It is possible to bytecode-compile modules into .mpy files, but those are compatible across all platforms, as far as I can tell (but not across all versions). On the other hand, the platforms themselves are not always perfectly compatible, even though there is an ongoing effort to bring them closer together, and to make most libraries work on all of the platforms without modifications. The Micro:bit platform is a kind of an outlier, since its default libraries are considerably different from those on other platforms (presumably to make them it easier to teach) -- which means that practically all hardware-related libraries need a separate micro:bit version. The PyBoard platfrom has as "pyb" module, retained for backwards compatibility, that is specific to it, side by side by the more general "machine" module, that is present on all platforms (except for the micro:bit) and which should work the same everywhere. In addition, different boards have different capabilities. The WiPy and ESP8266 boards have on-board WiFi and networking libraries, the PyBoard and micro:bit have an accelerometer, the WiPy lacks support for floating point numbers, etc. -- Radomir Dopieralski