Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
On Jun 19, 2013, at 4:50 PM, "Jason R. Coombs" wrote: > Donald, > What’s the next step to support this bootstrap script? Do we > need a ticket for PyPI to support this mechanism? How will PyPI resolve the > ‘latest’ virtual link when there are multiple non-hidden versions (as with > setuptools 0.7.4 and 0.6c11), or does the uploader make that determination? > > From: Donald Stufft [mailto:don...@stufft.io] > Sent: Monday, 10 June, 2013 14:15 > To: Jason R. Coombs > Cc: Tres Seaver; Distutils-Sig@Python.Org > Subject: Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility > wrapper) on PyPI > > > On Jun 10, 2013, at 2:55 PM, "Jason R. Coombs" wrote: > > > There seems to be a dominant opinion that the file should be on PyPI, and I > don't disagree. > > One issue is that the file must be mutable. It necessarily contains a > reference to the preferred version to be downloaded. That version changes > over time. It's typically incremented, but sometimes decremented. > > It's possible the script could be updated to otherwise discover the most > appropriate version. As it's currently implemented however, the file must be > expected to change over time. > > Because the file must change during each release, the system needs to be able > to accept an updated version. This is why the Bitbucket Link was referenced, > because it can include that version information. > > I'm open to suggestions on how we can create a perma link to a file that > changes over time on PyPI. > > Put a version in the filename/path, and have a "latest" tag that just 301 > redirects to whatever is latest. > > /bootstrap/setuptools/latest/ez_setup.py -> 301 Redirect to > /bootstrap/setuptools/0.7.2/ez_setup.py > > > > For now, the most authoritative place I could think of for that file was the > bit bucket downloads. Let's identify a mechanism to do the same on PyPI and > get that into set of tools for the next release. > > Sent from my comm > > - > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA I think we're going to make a small one off web app for uploading it. I'll see if I can whip something up. If it supports: * Uploading files * Versioned Urls * "Latest" url which redirects to the latest version Will that be enough for your uses? - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
On Wed, Jun 19, 2013 at 4:50 PM, Jason R. Coombs wrote: > > What’s the next step to support this bootstrap script? Can you just upload it with the docs? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout 2.2.0b1 is available fort testing
Jim Fulton writes: > > We'd like to release 2.2 final soon, so your testing is really > helpful. I tested this version and didn't run into any problems, though I didn't test the new stuff. -- Cheers Ralf ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI
Donald, What's the next step to support this bootstrap script? Do we need a ticket for PyPI to support this mechanism? How will PyPI resolve the 'latest' virtual link when there are multiple non-hidden versions (as with setuptools 0.7.4 and 0.6c11), or does the uploader make that determination? From: Donald Stufft [mailto:don...@stufft.io] Sent: Monday, 10 June, 2013 14:15 To: Jason R. Coombs Cc: Tres Seaver; Distutils-Sig@Python.Org Subject: Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI On Jun 10, 2013, at 2:55 PM, "Jason R. Coombs" mailto:jar...@jaraco.com> > wrote: There seems to be a dominant opinion that the file should be on PyPI, and I don't disagree. One issue is that the file must be mutable. It necessarily contains a reference to the preferred version to be downloaded. That version changes over time. It's typically incremented, but sometimes decremented. It's possible the script could be updated to otherwise discover the most appropriate version. As it's currently implemented however, the file must be expected to change over time. Because the file must change during each release, the system needs to be able to accept an updated version. This is why the Bitbucket Link was referenced, because it can include that version information. I'm open to suggestions on how we can create a perma link to a file that changes over time on PyPI. Put a version in the filename/path, and have a "latest" tag that just 301 redirects to whatever is latest. /bootstrap/setuptools/latest/ez_setup.py -> 301 Redirect to /bootstrap/setuptools/0.7.2/ez_setup.py For now, the most authoritative place I could think of for that file was the bit bucket downloads. Let's identify a mechanism to do the same on PyPI and get that into set of tools for the next release. Sent from my comm - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA smime.p7s Description: S/MIME cryptographic signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Binary installer on Windows can't install extension
> > I have no idea why the Windows linker attempts to load a x86 DLL into > > a x64 process. The manifest included with OpenVPN clearly shows that > > the DLL is for a different platform, even though it uses the same > > version as the one listed in the python.exe manifest. > > [snip] > > When Dependency Walker showed a reference from mxDateTime.pyd to > the > 32-bit version of MSVCR90.DLL, it always also showed a reference from > PYTHON27.DLL to the 64-bit version of MSVCR90.DLL. My suspicion is that this is due to OpenVPN adding itself to the PATH variable. The default Python install will put PYTHON27.DLL into System32 (for a 64-bit install), and so it will try and resolve dependencies in the same directory first. This is probably why it finds the correct MSVCR90.DLL (it may also be that the manifest is correct). Since mxDateTime.pyd is not in System32, it will go through the usual resolution process. System32 is supposed to be checked first, so I'm not sure why the correct version is being bypassed, but that may be because of the lack of manifest. I'd guess that it works for most people because by the time Windows reaches the end of its search, the correct DLL is the only/best/most recent option found. That OpenVPN version provides an alternative, and Windows is choosing it and then failing to load because of the platform mismatch. There's not much I can offer by way of solution. Adding a manifest to the pyd 'should' be the 'correct' solution, but I can't guarantee that it won't cause conflicts elsewhere. Adding a copy of MSVCR90.DLL to the pyd directory would also work, but this is probably riskier when it comes to version mismatches. As I understand, OpenVPN has corrected their side of things already, so this may just be an issue to be aware of for when people hit it in the future. Cheers, Steve ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Binary installer on Windows can't install extension
Am 19.06.2013 13:57, schrieb M.-A. Lemburg: > > The unresolved reference to MSVCR90.DLL is shown for all distutils > compiled extensions, so this is most likely the result of distutils > removing the manifest from compiled C extensions to force the linker > to use the Python DLL's CRT libs - this in return avoids problem with > having to place the CRT manifests into each extension directory. > After my initial problems, this now to works for me. I still don't understand what went wrong initially, though. > I have no idea why the Windows linker attempts to load a x86 DLL into > a x64 process. The manifest included with OpenVPN clearly shows that > the DLL is for a different platform, even though it uses the same > version as the one listed in the python.exe manifest. > I can a confirm this for the manifest included with OpenVPN 2.2.1 which I had installed before: When Dependency Walker showed a reference from mxDateTime.pyd to the 32-bit version of MSVCR90.DLL, it always also showed a reference from PYTHON27.DLL to the 64-bit version of MSVCR90.DLL. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Binary installer on Windows can't install extension
On 19.06.2013 12:51, M.-A. Lemburg wrote: > On 19.06.2013 10:01, Malte Forkel wrote: >> Am 19.06.2013 00:19, schrieb M.-A. Lemburg: >>> >>> Are you using our prebuilt or egg distribution of eGenix mx Base, >>> or compiling it from source ? >>> >> >> I'm using the prebuilt distribution >> (egenix-mx-base-3.2.6.win-amd64-py2.7.msi). >> >> Thanks to the kind advice of Steve Dower, I have since updated OpenVPN, >> the application had installed the 32-bit version of MSVCR90.DLL in its >> own directory, to a newer 64-bit version which does not install local CRTs. >> >> According to Dependency Walker, it had been OpenVPN's copy of >> MSVCR90.DLL that mxDateTime.pyd referenced, probably due to the >> OpenVPN's entry in the user's search path. > > Interesting. I just tried that on my system and indeed, see the > reference to OpenVPN as well. The same happens with all other .pyd > files in the Python installation. > >> Now, according to Dependency >> Walker, mxDateTime.pyd refeference to MSVCR90.DLL remains unresolved. >> But there are no problems when I run the install script or import >> mx.DateTime myself. > > We'll investigate that some more. It may have something to > do with the way distutils handles manifests for Python extensions > at compile/link time. The extensions should get all the MSVCR90.DLL > symbols from the DLL loaded into the PYTHON27.DLL process. The unresolved reference to MSVCR90.DLL is shown for all distutils compiled extensions, so this is most likely the result of distutils removing the manifest from compiled C extensions to force the linker to use the Python DLL's CRT libs - this in return avoids problem with having to place the CRT manifests into each extension directory. I have no idea why the Windows linker attempts to load a x86 DLL into a x64 process. The manifest included with OpenVPN clearly shows that the DLL is for a different platform, even though it uses the same version as the one listed in the python.exe manifest. -- Marc-Andre Lemburg Director Python Software Foundation http://www.python.org/psf/ ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Binary installer on Windows can't install extension
On 19.06.2013 10:01, Malte Forkel wrote: > Am 19.06.2013 00:19, schrieb M.-A. Lemburg: >> >> Are you using our prebuilt or egg distribution of eGenix mx Base, >> or compiling it from source ? >> > > I'm using the prebuilt distribution > (egenix-mx-base-3.2.6.win-amd64-py2.7.msi). > > Thanks to the kind advice of Steve Dower, I have since updated OpenVPN, > the application had installed the 32-bit version of MSVCR90.DLL in its > own directory, to a newer 64-bit version which does not install local CRTs. > > According to Dependency Walker, it had been OpenVPN's copy of > MSVCR90.DLL that mxDateTime.pyd referenced, probably due to the > OpenVPN's entry in the user's search path. Interesting. I just tried that on my system and indeed, see the reference to OpenVPN as well. The same happens with all other .pyd files in the Python installation. > Now, according to Dependency > Walker, mxDateTime.pyd refeference to MSVCR90.DLL remains unresolved. > But there are no problems when I run the install script or import > mx.DateTime myself. We'll investigate that some more. It may have something to do with the way distutils handles manifests for Python extensions at compile/link time. The extensions should get all the MSVCR90.DLL symbols from the DLL loaded into the PYTHON27.DLL process. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 19 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2013-06-18: Released mxODBC Django DE 1.2.0 ... http://egenix.com/go47 2013-07-01: EuroPython 2013, Florence, Italy ... 12 days to go 2013-07-16: Python Meeting Duesseldorf ... 27 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Binary installer on Windows can't install extension
Am 19.06.2013 00:19, schrieb M.-A. Lemburg: > > Are you using our prebuilt or egg distribution of eGenix mx Base, > or compiling it from source ? > I'm using the prebuilt distribution (egenix-mx-base-3.2.6.win-amd64-py2.7.msi). Thanks to the kind advice of Steve Dower, I have since updated OpenVPN, the application had installed the 32-bit version of MSVCR90.DLL in its own directory, to a newer 64-bit version which does not install local CRTs. According to Dependency Walker, it had been OpenVPN's copy of MSVCR90.DLL that mxDateTime.pyd referenced, probably due to the OpenVPN's entry in the user's search path. Now, according to Dependency Walker, mxDateTime.pyd refeference to MSVCR90.DLL remains unresolved. But there are no problems when I run the install script or import mx.DateTime myself. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
