Re: [Distutils] Round 6 - PEP 440 - Version Identification and Dependency Specification Version
On 8 August 2014 22:53, Donald Stufft don...@stufft.io wrote: Direct references = Some automated tools may permit the use of a direct reference as an alternative to a normal version specifier. A direct reference consists of the specifier ``@`` and an explicit URL. Whether or not direct references are appropriate depends on the specific use case for the version specifier. Automated tools SHOULD at least issue warnings and MAY reject them entirely when direct references are used inappropriately. Public index servers SHOULD NOT allow the use of direct references in uploaded distributions. Direct references are intended as a tool for software integrators rather than publishers. Depending on the use case, some appropriate targets for a direct URL reference may be a valid ``source_url`` entry (see PEP 426), an sdist, or a wheel binary archive. The exact URLs and targets supported will be tool dependent. For example, a local source archive may be referenced directly:: pip @ file:///localbuilds/pip-1.3.1.zip Alternatively, a prebuilt archive may also be referenced:: pip @ file:///localbuilds/pip-1.3.1-py33-none-any.whl One very minor question. Is URL format required here? I guess so. On Windows, file URLs are confusing and annoying to type - use of / rather than \ makes tab-completion useless, it's difficult to remember how many slashes go at the start and where the drive letter goes, and do UNC paths need 157 or 158 slashes at the start (:-)), and the documentation is inconsistent and hard to find. Allowing a pathname here would be convenient for users, but it's 100% not important enough to need a new version of the spec. A clarification (presumably, that a URL is required) with a pointer to a document that explains the relevant filename-URL translation algorithm, would be good, though. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Round 6 - PEP 440 - Version Identification and Dependency Specification Version
On Aug 9, 2014, at 4:26 AM, Paul Moore p.f.mo...@gmail.com wrote: On 8 August 2014 22:53, Donald Stufft don...@stufft.io wrote: Direct references = Some automated tools may permit the use of a direct reference as an alternative to a normal version specifier. A direct reference consists of the specifier ``@`` and an explicit URL. Whether or not direct references are appropriate depends on the specific use case for the version specifier. Automated tools SHOULD at least issue warnings and MAY reject them entirely when direct references are used inappropriately. Public index servers SHOULD NOT allow the use of direct references in uploaded distributions. Direct references are intended as a tool for software integrators rather than publishers. Depending on the use case, some appropriate targets for a direct URL reference may be a valid ``source_url`` entry (see PEP 426), an sdist, or a wheel binary archive. The exact URLs and targets supported will be tool dependent. For example, a local source archive may be referenced directly:: pip @ file:///localbuilds/pip-1.3.1.zip Alternatively, a prebuilt archive may also be referenced:: pip @ file:///localbuilds/pip-1.3.1-py33-none-any.whl One very minor question. Is URL format required here? I guess so. On Windows, file URLs are confusing and annoying to type - use of / rather than \ makes tab-completion useless, it's difficult to remember how many slashes go at the start and where the drive letter goes, and do UNC paths need 157 or 158 slashes at the start (:-)), and the documentation is inconsistent and hard to find. Allowing a pathname here would be convenient for users, but it's 100% not important enough to need a new version of the spec. A clarification (presumably, that a URL is required) with a pointer to a document that explains the relevant filename-URL translation algorithm, would be good, though. Paul To be clear, the direct reference is mostly for use in the install_requires. On the CLI pip can still just take a path to a file or whatever. This feature is intended to replace dependency_links in a way that people can use them for private packages but that they won't be allowed on PyPI or the like. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Round 6 - PEP 440 - Version Identification and Dependency Specification Version
On 9 August 2014 17:02, Donald Stufft don...@stufft.io wrote: To be clear, the direct reference is mostly for use in the install_requires. On the CLI pip can still just take a path to a file or whatever. This feature is intended to replace dependency_links in a way that people can use them for private packages but that they won't be allowed on PyPI or the like. Understood. I'd still like an explicit pointer to the canonical URL details tools should (or must?) use. See http://en.wikipedia.org/wiki/File_URI_scheme (specifically the Windows sections) for why I'm bothered - specifically the quote Here are *some* examples which *may* be accepted by some applications (emphasis mine). I'd be more than happy if the spec was just tools will use XXX from the Python standard library. But note (the first 4 are the supposedly acceptable URLs from that Wikipedia article): py Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. from urllib.request import url2pathname url2pathname(file://localhost/c|/WINDOWS/clock.avi) Traceback (most recent call last): File stdin, line 1, in module File C:\Apps\Python34\lib\nturl2path.py, line 26, in url2pathname raise OSError(error) OSError: Bad URL: file|//localhost/c|/WINDOWS/clock.avi url2pathname(file:///c|/WINDOWS/clock.avi) Traceback (most recent call last): File stdin, line 1, in module File C:\Apps\Python34\lib\nturl2path.py, line 26, in url2pathname raise OSError(error) OSError: Bad URL: file|///c|/WINDOWS/clock.avi url2pathname(file://localhost/c:/WINDOWS/clock.avi) Traceback (most recent call last): File stdin, line 1, in module File C:\Apps\Python34\lib\nturl2path.py, line 26, in url2pathname raise OSError(error) OSError: Bad URL: file|//localhost/c|/WINDOWS/clock.avi url2pathname(file:///c:/WINDOWS/clock.avi) Traceback (most recent call last): File stdin, line 1, in module File C:\Apps\Python34\lib\nturl2path.py, line 26, in url2pathname raise OSError(error) OSError: Bad URL: file|///c|/WINDOWS/clock.avi url2pathname(file:WINDOWS/clock.avi) 'E:\\WINDOWS\\clock.avi' url2pathname(file:///WINDOWS/clock.avi) 'E:\\WINDOWS\\clock.avi' url2pathname(file://WINDOWS/clock.avi) 'E:\\WINDOWS\\clock.avi' url2pathname(file:/WINDOWS/clock.avi) 'E:\\WINDOWS\\clock.avi' I have no idea where Python got that E drive from - my current drive is C:. At this point in time, I have no idea how to correctly write a file URL for the file C:\Windows\clock.avi on my PC. While it's very definitely a corner case in the PEP, and it's clearly not the PEP's responsibility to explain the file URL spec, I do think it's relevant to the usability of the PEP. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Round 6 - PEP 440 - Version Identification and Dependency Specification Version
On Aug 9, 2014, at 1:41 PM, Paul Moore p.f.mo...@gmail.com wrote: On 9 August 2014 17:02, Donald Stufft don...@stufft.io wrote: To be clear, the direct reference is mostly for use in the install_requires. On the CLI pip can still just take a path to a file or whatever. This feature is intended to replace dependency_links in a way that people can use them for private packages but that they won't be allowed on PyPI or the like. Understood. I'd still like an explicit pointer to the canonical URL details tools should (or must?) use. See http://en.wikipedia.org/wiki/File_URI_scheme (specifically the Windows sections) for why I'm bothered - specifically the quote Here are *some* examples which *may* be accepted by some applications (emphasis mine). I'd be more than happy if the spec was just tools will use XXX from the Python standard library. But note (the first 4 are the supposedly acceptable URLs from that Wikipedia article): py Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. from urllib.request import url2pathname url2pathname(file://localhost/c|/WINDOWS/clock.avi) Traceback (most recent call last): File stdin, line 1, in module File C:\Apps\Python34\lib\nturl2path.py, line 26, in url2pathname raise OSError(error) OSError: Bad URL: file|//localhost/c|/WINDOWS/clock.avi url2pathname(file:///c|/WINDOWS/clock.avi) Traceback (most recent call last): File stdin, line 1, in module File C:\Apps\Python34\lib\nturl2path.py, line 26, in url2pathname raise OSError(error) OSError: Bad URL: file|///c|/WINDOWS/clock.avi url2pathname(file://localhost/c:/WINDOWS/clock.avi) Traceback (most recent call last): File stdin, line 1, in module File C:\Apps\Python34\lib\nturl2path.py, line 26, in url2pathname raise OSError(error) OSError: Bad URL: file|//localhost/c|/WINDOWS/clock.avi url2pathname(file:///c:/WINDOWS/clock.avi) Traceback (most recent call last): File stdin, line 1, in module File C:\Apps\Python34\lib\nturl2path.py, line 26, in url2pathname raise OSError(error) OSError: Bad URL: file|///c|/WINDOWS/clock.avi url2pathname(file:WINDOWS/clock.avi) 'E:\\WINDOWS\\clock.avi' url2pathname(file:///WINDOWS/clock.avi) 'E:\\WINDOWS\\clock.avi' url2pathname(file://WINDOWS/clock.avi) 'E:\\WINDOWS\\clock.avi' url2pathname(file:/WINDOWS/clock.avi) 'E:\\WINDOWS\\clock.avi' I have no idea where Python got that E drive from - my current drive is C:. At this point in time, I have no idea how to correctly write a file URL for the file C:\Windows\clock.avi on my PC. While it's very definitely a corner case in the PEP, and it's clearly not the PEP's responsibility to explain the file URL spec, I do think it's relevant to the usability of the PEP. Paul Does: file:///c:/WINDOWS/clock.avi work? That’s pointed out in the wikipage you linked as to what IE has done since IE4 and seems to be the most reasonable candidate. It also uses file://remotehost/sharename/dir/file.txt for UNC paths apparently. I misunderstood the problem though, I thought you were worried about needing to type out the file:// and the slash order on the CLI, not referencing files at all. We can absolutely add more details to the PEP. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Round 6 - PEP 440 - Version Identification and Dependency Specification Version
On 9 August 2014 18:50, Donald Stufft don...@stufft.io wrote: Does: file:///c:/WINDOWS/clock.avi work? Never mind, it's my mistake. Reading the docs more closely, Convert the path component path from a percent-encoded URL to the local syntax for a path. This does not accept a complete URL. (Note that second sentence...) url2pathname(///c:/WINDOWS/clock.avi) 'C:\\WINDOWS\\clock.avi' Looks like the PEP would be covered by referring to pathname2url/url2pathname (with a note that you strip the file: prefix for idiots like me ;-)) and giving a couple of examples. FWIW, it looks like file:myserver/share/WINDOWS/clock.avi is how you'd refer to \\myserver\share\WINDOWS\clock.avi. See what I mean about the slashes? I can't rationalise the 4 slashes here resulting in two backslashes, when the 3 slashes above disappear entirely... Paul. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Round 6 - PEP 440 - Version Identification and Dependency Specification Version
Paul Moore wrote: FWIW, it looks like file:myserver/share/WINDOWS/clock.avi is how you'd refer to \\myserver\share\WINDOWS\clock.avi. Where did you get that from? According to this it's wrong: http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows.aspx It should be file://myserver/share/WINDOWS/clock.avi i.e. the hosthame part of the path goes into the hostname part of the URI, which makes sense. If the path uses a drive letter instead, there is no hostname, so that part of the URI is empty, resulting in three consecutive slashes: file:///c:/WINDOWS/clock.avi -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
