Medio ambiente

• versión pip: 19.1.1
• Versión de Python: 3.7
• SO: MacOS Mojave

Descripción
No estoy seguro de si esto es un error de six o un error de Pip. Disculpe si pertenece a six .

Pip parece permitir rutas locales en install_requires través de name @ ./some/path , pero el análisis de URL está terriblemente roto.

https://github.com/pypa/pip/blob/a38a0eacd4650a7d9af4e6831a2c0aed0b6a0329/src/pip/_internal/download.py#L670 -L690

En esta función, usa urlsplit para obtener los componentes individuales de la URL entrante.

Así es como se ve con algunas piezas de entrada:

./foo/bar -> SplitResult(scheme='', netloc='', path='./foo/bar', query='', fragment='')
file:./foo/bar -> SplitResult(scheme='file', netloc='', path='./foo/bar', query='', fragment='')
file://./foo/bar -> SplitResult(scheme='file', netloc='.', path='/foo/bar', query='', fragment='')

Observe que el último da como resultado que netloc sea . lugar de estar vacío y que path sea ​​absoluto, no local. Esto dispara el error con respecto a rutas no locales. Eso está muy bien, puedo usar la segunda forma para satisfacer la lógica condicional (aunque realmente debería admitir la primera también).

Sin embargo, hay una lógica conflictiva en otros lugares ...

https://github.com/pypa/pip/blob/169eebdb6e36a31e545804228cad94902a1ec8e9/src/pip/_vendor/packaging/requirements.py#L103 -L106

Esta es la lógica que falla a pesar de que satisfacemos la lógica anterior.

Aquí hay una función de prueba que muestra el problema:

from six.moves.urllib import parse as urllib_parse

def tryparse(url):
    print(url)
    parsed = urllib_parse.urlparse(url)
    unparsed = urllib_parse.urlunparse(parsed)
    parsed_again = urllib_parse.urlparse(unparsed)
    print(parsed)
    print(unparsed)
    print(parsed_again)

Aquí está la salida de ./foo/bar :

>>> tryparse('./foo/bar')
./foo/bar
ParseResult(scheme='', netloc='', path='./foo/bar', params='', query='', fragment='')
./foo/bar
ParseResult(scheme='', netloc='', path='./foo/bar', params='', query='', fragment='')

Todo bien, aunque no satisface la lógica de la primera función de requerir un esquema de file: .

Aquí está la salida de file:./foo/bar :

>>> tryparse('file:./foo/bar')
file:./foo/bar
ParseResult(scheme='file', netloc='', path='./foo/bar', params='', query='', fragment='')
file:///./foo/bar
ParseResult(scheme='file', netloc='', path='/./foo/bar', params='', query='', fragment='')

¡Ups! Observe cómo, cuando "descomprimimos" el resultado de la primera llamada de análisis, nuestro path convierte en absoluto file:///... .

Esta es la razón por la que falla la segunda verificación mencionada: la ruta no es local. Creo que esto es un error en six pero se puede mitigar en Pip permitiendo scheme in ['file', ''] e indicando a los usuarios que usen el formulario ./foo/bar URI.

Teniendo en cuenta estas dos piezas contradictorias de la lógica, es imposible utilizar las rutas locales en install_requires llaves, ya sea en distutils o setuptools configuraciones.

Comportamiento esperado
Debería poder hacer name @ ./some/path (o, honestamente, simplemente ./some/path ) para especificar un paquete vendored local a mi base de código.

Cómo reproducir

#!/usr/bin/env bash
mkdir /tmp/pip-uri-repro && cd /tmp/pip-uri-repro

mkdir -p foo/bar

cat > requirements.txt <<EOF
./foo
EOF

cat > foo/setup.py <<EOF
#!/usr/bin/env python
from setuptools import setup
setup(
    name="foo",
    version="0.1",
    install_requires=[
        "bar @ file:./bar"
    ]
)
EOF

cat > foo/bar/setup.py <<EOF
#!/usr/bin/env python
from setuptools import setup
setup(
    name="bar",
    version="0.1"
)
EOF

# (OUTPUT 1)
pip install -r requirements.txt

cat > foo/setup.py <<EOF
#!/usr/bin/env python
from setuptools import setup
setup(
    name="foo",
    version="0.1",
    install_requires=[
        # we're forced to use an absolute path
        # to make the "Invalid URL" error go
        # away, which isn't right anyway (the
        # error that is raised as a result
        # is justified)
        "bar @ file://./bar"
    ]
)
EOF

# (OUTPUT 2)
pip install -r requirements.txt

Salida

Desde el primer pip install :

Processing ./foo
    ERROR: Complete output from command python setup.py egg_info:
    ERROR: error in foo setup command: 'install_requires' must be a string or list of strings containing valid project/version requirement specifiers; Invalid URL given

Desde el segundo pip install :

Processing ./foo
ERROR: Exception:
Traceback (most recent call last):
  File "/private/tmp/repro-pip-egg/env3/lib/python3.7/site-packages/pip/_internal/cli/base_command.py", line 178, in main
    status = self.run(options, args)
  File "/private/tmp/repro-pip-egg/env3/lib/python3.7/site-packages/pip/_internal/commands/install.py", line 352, in run
    resolver.resolve(requirement_set)
  File "/private/tmp/repro-pip-egg/env3/lib/python3.7/site-packages/pip/_internal/resolve.py", line 131, in resolve
    self._resolve_one(requirement_set, req)
  File "/private/tmp/repro-pip-egg/env3/lib/python3.7/site-packages/pip/_internal/resolve.py", line 294, in _resolve_one
    abstract_dist = self._get_abstract_dist_for(req_to_install)
  File "/private/tmp/repro-pip-egg/env3/lib/python3.7/site-packages/pip/_internal/resolve.py", line 242, in _get_abstract_dist_for
    self.require_hashes
  File "/private/tmp/repro-pip-egg/env3/lib/python3.7/site-packages/pip/_internal/operations/prepare.py", line 256, in prepare_linked_requirement
    path = url_to_path(req.link.url)
  File "/private/tmp/repro-pip-egg/env3/lib/python3.7/site-packages/pip/_internal/download.py", line 521, in url_to_path
    % url
ValueError: non-local file URIs are not supported on this platform: 'file://./bar'

EDITAR:

Acabo de descubrir que RFC 3986 especifica que los URI de ruta relativa no están permitidos con el esquema file: , por lo que técnicamente six debería tener un error en file:./foo/bar .

Sin embargo, eso significa que, técnicamente, debería poder hacer lo siguiente en mi setup.py:

PKG_DIR = os.path.dirname(os.path.abspath(__file__))
install_requires = [
    f"name @ file://{PKG_DIR}/foo/bar"
]

Sin embargo, pip parece estar creando una copia "limpia" del paquete en /tmp , por lo que obtenemos algo como file:///tmp/pip-req-build-9u3z545j/foo/bar .

Ejecutando eso a través de nuestra función de prueba, satisfacemos el condicional de la segunda función:

>>> tryparse('file:///tmp/pip-req-build-9u3z545j/foo/bar')
file:///tmp/pip-req-build-9u3z545j/foo/bar
ParseResult(scheme='file', netloc='', path='/tmp/pip-req-build-9u3z545j/foo/bar', params='', query='', fragment='')
file:///tmp/pip-req-build-9u3z545j/foo/bar
ParseResult(scheme='file', netloc='', path='/tmp/pip-req-build-9u3z545j/foo/bar', params='', query='', fragment='')

Todo va bien ahí. El "no analizar" produce el mismo resultado, y se cumplen los requisitos netloc para el condicional de la primera función.

Sin embargo, todavía nos encontramos con un error de Invalid URL , aunque se satisface la lógica de la segunda función.

Dado que pip (o distutils o setuptools o lo que sea) se traga la salida, seguí adelante e hice lo siguiente en mi setup.py

import os
PKG_DIR = os.path.dirname(os.path.abspath(__file__))
assert False, os.system(f"find {PKG_DIR}")

Lo que verifica que todos los archivos estén allí, como se esperaba, por lo que no puede faltar un archivo o algo así. La línea de arriba que tiene "Invalid URL given" es el único lugar en el código base donde aparece la cadena.

En este punto, no estoy seguro de cuál es el problema.