+1, подтверждено в Mac OS X 10.7.3 и Python 2.7.1

Немного раздражает, было бы здорово исправить

Мы можем создать virtualenv с пробелами в имени (см. # 278), но easy_install и pip наткнутся на него позже:

% virtualenv "foo bar"
New python executable in foo bar/bin/python
Installing setuptools............done.
Installing pip...............done.
% ./foo\ bar/bin/easy_install nose
zsh: ./foo bar/bin/easy_install: bad interpreter: "/tmp/cfl/foo: no such file or directory
127 % ./foo\ bar/bin/pip install nose 
zsh: ./foo bar/bin/pip: bad interpreter: "/tmp/cfl/foo: no such file or directory

Я также здесь, чтобы подтвердить, что это проблема OS X (здесь 10.8). Если вы отредактируете переменную VIRTUAL_ENV и shebangs в bin, вы можете заставить ее работать, но свежий env захлебнется в любых пробелах в пути. Это большая проблема для OS X, учитывая, что загрузочный диск обычно называется «Macintosh HD», поэтому каждый путь начинается с «/ Volumes / Macintosh HD ...»

Хак, который я использую, работает следующим образом.

bin / активировать:

VIRTUAL_ENV='/Volumes/Macintosh\ HD/path/to/my/project'

bin / pip и bin / easy_install:

#!"/Volumes/Macintosh\ HD/path/to/my/project/venv/bin/python"

Пип, похоже, работает после выхода из пробела на пути.

Почему это было закрыто? Это по-прежнему серьезная проблема. исправь мою ошибку, она все еще открыта

эта проблема все еще остается открытой.

Мне удалось обойти это, создав символическую ссылку из моего домашнего каталога на тот, в котором я хотел работать (в противном случае в нем было место).

Я тоже это вижу, потому что Mac. Я обхожу это, вручную редактируя строку shebang в скриптах на! # / Usr / bin / env python, и все работает. Однако, как отмечали другие, это необходимо делать с каждым новым env и любыми дополнительными скриптами, установленными в env.
Кажется, это должно быть легкое исправление в коде, чтобы либо избежать пробела, либо использовать / usr / bin / env, если is_darwin. Однако, поскольку я в значительной степени новичок в этом, я могу ошибаться.

Это не только для Mac, это в основном часть спецификации / поведения систем * nix.

У вас не может быть пробелов в первом аргументе строки shebang (вместо этого они будут преобразованы в отдельные аргументы), и, как правило, также не допускается экранирование / цитирование.

http://lists.gnu.org/archive/html/bug-bash/2008-05/msg00053.html

Я знаю, я тоже столкнулся с этой проблемой с анакондой. Это просто характерно для Mac, потому что в имени диска есть пробелы.

Похоже, это будет исправлено # 611. Был ли какой-нибудь обзор эффективности этого запроса на вытягивание?

Это раздражает, нужно исправить как можно скорее.

См. Ссылку @Ivoz , это ограничение Unix. # 611 может работать для некоторых вариантов Unix, если они поддерживают экранирование обратной косой черты в строке shebang, но неясно, какие версии работают (и код просто делает это вслепую без проверки - что, по общему признанию, не усугубит проблему, но победило '' не помогите, если он не поддерживается ...)

Это действительно правда, что это результат того, как unix обрабатывает строки shebang, но если # 611 устранит проблему для некоторых систем и не усугубит проблему для других, будет ли это улучшением?

Если это правда, то да. Но я не могу комментировать # 611, так как я не разработчик Unix. Могут быть случаи, когда это только ухудшает ситуацию, я просто не знаю. Извините, я ничем не могу вам помочь.

Справедливо. # 611, вероятно, следует более внимательно изучить и протестировать на наличие второстепенных случаев.

Еще хуже: в Windows он ломается по пути Jenkins по умолчанию с той же ошибкой:
FATAL: пробелы не допускаются в пути интерпретатора Python: C: \ Program Files (x86) \ Jenkins \ shiningpanda \ jobs \ c3418983virtualenvs \ d41d8cd9

Меня как раз затронула эта проблема. Следуя инструкциям, которые я нашел в StackOverflow , мне удалось заставить pip работать, просто установив в первой строке значение #!/usr/bin/env python

Однако я не уверен, работает ли это решение для всех случаев ... Я имею в виду, я не уверен, какой Python будет запущен

Изменение набора установленных скриптов на «env python» означает, что они будут работать только в активированном virtualenv. Сценарии были созданы с явными абсолютными путями, чтобы они всегда использовали Python в venv и, таким образом, находили установленные пакеты, необходимые для сценариев.

Мое предложение состояло бы в том, чтобы кто-то (возможно, кто-то, затронутый этой проблемой, но, как минимум, кто-то на платформе, у которой есть проблема, а также имеет способ ее решения), предоставил запрос на перенос, реализующий проверку по строкам:

• Если в имени пути есть пробелы,
• и мы на платформе XXX,
• затем напишите строку shebang со следующим экранированием, чтобы обработать пробелы.
• Во всех остальных случаях вернитесь к текущему поведению.

Затем заинтересованные стороны могут внести дополнительные дополнения, просто добавив дополнительные проверки платформы.

В идеале было бы неплохо включить комментарий со ссылкой на документацию, подтверждающую, как платформа XXX поддерживает пути с пробелами, чтобы будущие сопровождающие имели ссылку для проверки. Лично мне непонятно, какие исправления работают и где:

1. обсуждение здесь предполагает, что двойные кавычки работают в OSX, но зависит ли это от точной версии OSX?
2. В # 611 использовались экранирующие пробелы с обратной косой чертой, но не было подтверждения, для какой ОС он предназначен (Linux? Определенная версия ядра? Определенный дистрибутив?)

Обратите внимание, что никакие такие варианты для конкретной платформы не должны использовать /usr/bin/env . Как отметил @merwok , это приводит к изменению поведения - shebang намеренно написан, чтобы разрешить запуск сценария _без_ активации среды.

Добавление некоторых тестов, чтобы убедиться, что поведение соответствует ожиданиям (включая принцип, согласно которому оно отключается, когда мы не на специально признанной платформе), также было бы чрезвычайно полезно, но это также было бы неудобно, поскольку это потребовало бы исправления обезьяны для разрешить тестирование платформы XXX, когда вы фактически не работаете на этой платформе.

@pfmoore Как я уже упоминал, я недавно

экранирование с помощью обратной косой черты или кавычек не будет работать, согласно https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00052.html

Экспериментально я могу проверить, что экранирование с помощью обратной косой черты или кавычек не работает с OSX 10.11.6.

virtualenv не следует использовать shebang, зависящие от ядра. Я проверил исходные коды Linux, XNU (ядро macOS), FreeBSD, OpenBSD и NetBSD. Ни один из них не может обрабатывать пробелы в shebang.

Пока не будет исправления, не используйте пробелы.

Я отправляю патч, который добавляет предупреждение для нового venv Python 3, который очень похож на virtualenv, но отклонен @vsajip : http://bugs.python.org/issue28446. На самом деле это вина не Python, а операционной системы. Может, этот вопрос можно закрыть?

В качестве дополнительной точки данных обратите внимание на поведение в Windows, которое кажется ожидаемым:

`` C: \ Users \ Vinay> \ python34 \ python -m venv "\ Temp \ aaa bbb"

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" --version
pip 6.0.8 из C: \ Temp \ aaa bbb \ lib \ site-packages (python 3.4)

C: \ Users \ Vinay> pyzzer -i "\ Temp \ aaa bbb \ Scriptspip.exe"
Есть лаунчер.
Shebang: #! "C: \ Temp \ aaa bbb \ Scripts \ python.exe"

Содержание архива:
__main__.py

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scripts \ python" -m pip install -U pip
Вы используете версию 6.0.8 pip, однако доступна версия 9.0.1.
Вам следует рассмотреть возможность обновления с помощью команды pip install --upgrade pip.
Сбор pip с https://pypi.python.org/ [...] / pip-9.0.1-py2.py3-none-any.whl # md5 = 297 [...]
Использование кешированного pip-9.0.1-py2.py3-none-any.whl
Установка собранных пакетов: pip
Найдена существующая установка: pip 6.0.8
Удаление pip-6.0.8:
Успешно удален pip-6.0.8

Успешно установлен pip-9.0.1

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" --version
pip 9.0.1 из C: \ Temp \ aaa bbb \ lib \ site-packages (python 3.4)
``

Да, скрипты virtualenv в Windows работают, поскольку distlib определяет собственный протокол shebang в файле PC / launcher.c. Может быть, в POSIX может быть что-то похожее - парсер shebang пространства пользователя вместо ненадежных ядер.

парсер shebang пространства пользователя вместо ненадежных ядер

Я не уверен, почему Bash не может этого сделать (например) - я не думаю, что это связано с пространством ядра.

Шебанги обрабатываются в пространстве ядра, потому что их следует использовать вне оболочки.

Технические подробности:
В UNIX-подобных системах (Linux, Mac, * BSD, ...) новая программа создается с помощью fork () и exec (). exec () похож на CreateProcess () в Windows, который запускает новую программу. В UNIX-подобных системах exec () в конечном итоге вызывает системный вызов execve (). Последняя функция реализована в ядрах, поэтому синтаксический анализ shebang выполняется в ядрах.
Он также не может быть реализован в библиотеках C, либо статические связанные программы или программы, которые напрямую используют системные вызовы (через int 80 или sysenter и т. Д.), Не будут работать.

Может, стоит просто запретить создание виртуальной среды с пробелами в пути. В любом случае это не будет работать должным образом

Шебанги обрабатываются в пространстве ядра, потому что их можно использовать вне оболочки.

Да, но не могла ли оболочка выполнить синтаксический анализ самостоятельно, если системный вызов вернул ENOEXEC ? Я понимаю, что это может быть банка с червями ...

Интересный лакомый кусочек - функциональность ядра в Linux, похоже, была написана давним коммиттером Python Мартином фон Лёвисом :-)

Эта страница также была интересной для чтения: http://www.in-ulm.de/~mascheck/various/shebang/

Да, но не могла ли оболочка выполнить синтаксический анализ самостоятельно, если системный вызов вернул ENOEXEC ?

ИМО, различная семантика между оболочками и базовым ядром может вызвать путаницу как у пользователей, так и у разработчиков. В настоящее время, по крайней мере, bash и zsh выполняют синтаксический анализ при сбое execve (), но только для лучшего сообщения об ошибках, а не для восстановления.

Интересный лакомый кусочек - функциональность ядра в Linux, похоже, была написана давним коммиттером Python Мартином фон Лёвисом :-)

Интересно! Я этого не заметил :) Также спасибо за дополнительный материал. Хотя чтение исходного кода ядра - самый быстрый способ, такие документы все же полезны.

Об идее @fbidu :

Может, стоит просто запретить создание виртуальной среды с пробелами в пути. В любом случае это не будет работать должным образом

Создание виртуальных сред с хрупкими путями полезно для тестирования угловых ситуаций при обработке путей. В этом примере показано, как ломаются ядра. Моя идея - добавить предупреждения вместо запрета, как и в патче, который я разместил на http://bugs.python.org/issue28446

Я думаю, что №994 «Пип терпит неудачу с пробелом в пути virtualenv» - дубликат этой проблемы.

Я хочу повторить комментарий из https://github.com/pypa/virtualenv/issues/997#issuecomment -270681253, «virtualenv нарушены из-за хрупкого разбора ядра shebang». И в этом духе, # 1014 «Несовместимо с каталогом, в пути которого есть смайлы» - еще один пример того, как virtualenv нарушается из-за хрупкого синтаксического анализа ядра shebang. Готов поспорить, что проблема действительно возникает с любыми не-ASCII символами в пути.

Может быть, нам следует собрать все три аспекта хрупкого разбора ядра shebang в одну проблему, чтобы мы могли быть уверены, что одно исправление может адресовать пробелы, длину и символы, отличные от ASCII, в пути virtualenv? Номинирую этот выпуск, потому что он самый старый.

Пока мы работаем над исправлением, я думаю, что для virtualenv было бы хорошо выводить предупреждение, когда его просят создать среду на пути, который а) имеет пробелы, б) слишком длинный или в) содержит символы, отличные от ASCII. Также поможет предложение в некоторой документации.

Готов поспорить, что проблема действительно возникает с любыми не-ASCII символами в пути.

Я считаю, что причина # 1014 кроется в virtualenv, а не в ядре. У меня есть патч, исправляющий очень похожую проблему на # 900.

Привет всем,
Это очень раздражает и такая огромная трата времени из-за чего-то, казалось бы, такого простого (по крайней мере, по простой причине).

Как насчет переименования (если возможно) или использования ссылок (создание каталога, такого как /virtualenvs/python3.5, без пробела, а затем использование мягкой ссылки на исходный каталог?)

создание каталога, такого как /virtualenvs/python3.5, без пробела

Другой проект, virtualenvwrapper, сделал нечто подобное.

что-то вроде бы такое простое (по крайней мере, по простой причине).

Ни то ни другое не является простым. Причина связана с кодами синтаксического анализа ядра, и обходной путь требует обработки shebang в пользовательском пространстве.

Спустя 6 лет это все еще проблема?

Эта проблема сбила меня с толку 2 недели назад. Да, это все еще проблема.

Обратите внимание: поскольку это проблема Unix, а не проблема virtualenv, маловероятно, что она будет "исправлена", если ограничение ядра Unix не будет снято ...

Первая ошибка virtualenv заключается в том, что virtualenv решил реализовать исполняемые файлы оболочки с помощью определенной функции ядра Unix, несмотря на то, что эта функция имеет ограничения, которые обычно вызывают проблемы для пользователя virtualenv. Virtualenv может исправить это, используя другой механизм для исполняемых файлов оболочки. Вторая ошибка virtualenv - отсутствие документации о том, как пользователи должны использовать virtualenv, чтобы обойти первую ошибку (создавать virtualenv только на коротких путях с символами только ASCII и без пробелов). Третья ошибка virtualenv заключается в том, что у него нет механизма, который обнаруживает случаи, когда пользователь выбирает путь virtualenv, который вызывает первую ошибку, и выводит полезное предупреждающее сообщение. Соавторы virtualenv могут многое сделать, чтобы улучшить ситуацию.

@JDLH О вашей первой «ошибке»: она обрабатывается не virtualenv, а distlib, и есть реализация на https://bitbucket.org/pypa/distlib/pull-requests/31/. Я надеюсь, что у меня будет время изучить внутреннее устройство distlib и правильно ответить на комментарии Виная Саджипа, но, к сожалению, у меня нет.

Первая ошибка virtualenv заключается в том, что virtualenv решил реализовать исполняемые файлы оболочки с помощью определенной функции ядра Unix.

@JDLH Это не относится к virtualenv - _все_ файлы сценария Unix (то есть файлы со строками shebang) используют эту функцию ядра - и нет веских причин для virtualenv (или чего-то еще) изобретать заново совершенно новый метод диспетчеризации скриптов, когда существующий механизм так широко используется и хорошо изучен. Если вы написали сценарий вручную, в пути к интерпретатору были пробелы (без virtualenv ), возникла бы та же проблема.

Соавторы virtualenv могут многое сделать, чтобы улучшить ситуацию.

Вероятно, у участников много времени. Эта проблема затрагивает относительно небольшое количество случаев, когда используются длинные пути / пути с пробелами. Возможно, некоторые из этих пользователей, которые затронуты, могли бы помочь участникам помочь им, предложив патч, который поможет с сообщениями об обнаружении и предупреждениями? Просто идея.

@ yan12125 distlib позволяет указать исполняемый файл в строке shebang как угодно. Ограничение ядра на пробелы / длинные строки, возможно, никогда не будет исправлено разработчиками Linux из-за обратной совместимости. Можно просто предоставить настраиваемую строку для исполняемого файла shebang (включая обобщенный эквивалент взлома сценария Mozilla), и distlib должен записать ее в сценарий, чтобы с ней можно было экспериментировать как с distlib user (следовательно, без _необходимости_ смотреть на внутренности, AFAICT).

Это не относится к virtualenv

@vsajip Это верное утверждение - другое программное обеспечение использует тот же механизм shebang, который выбрал virtualenv, - но оно упускает из виду суть этой проблемы. В значении virtualenv нет ничего, что требовало бы использования shebang. virtualenv мог использовать другой механизм, но он выбрал shebang, и поэтому virtualenv действительно наследует ограничение shebang.

у virtualenv (или чего-то еще) нет веских причин изобретать совершенно новый метод отправки скриптов

Я думаю, что вы говорите о том, что проблемы, с которыми сталкиваются люди, сталкивавшиеся с этой проблемой на протяжении многих лет, не являются «неотложными». Я думаю, что причина, по которой так много людей находят и комментируют эту проблему на протяжении многих лет, заключается в том, что они действительно находят проблемы «неотложными». Конечно, знаю.

Возможно, некоторые из этих пользователей, которые затронуты, могли бы помочь участникам помочь им, предложив патч, который поможет с сообщениями об обнаружении и предупреждениями? Просто идея.

Я выбрал слово «участники», чтобы включить как стойких, которые выполняют большую часть работы над virtualenv, так и посетителей вроде меня, которые считают эту проблему достаточно убедительной, чтобы работать над уменьшением ее воздействия. Справедливо сказать, что мы, для тех, кто считает проблему неотразимой, должны внести исправление.

Было бы полезно, если бы стойкие, хорошо знающие virtualenv, предложили многообещающие подходы. Если бы я хотел вставить предупреждающее сообщение для пользователя, который вводит virtualenv ~/my\ long\ path\ with\ spaces , где лучше всего разместить этот код? Есть ли в таком патче неочевидные ограничения, которыми могли бы поделиться стойкие, чтобы убрать препятствие для посетителя, работающего над своим первым вкладом? Есть ли у стойких приверженцев какие-то исторические возражения против принятия такого патча? (Я имею в виду, что я не могу быть первым, кто придумал добавить предупреждающее сообщение. Должна быть причина, по которой этого еще не произошло.)

Есть один хорошо известный путь, который содержит пробелы и не может быть изменен: /Users/iulian/Library/Mobile Documents/com~apple~CloudDocs . Таким образом, любой, кто хочет, чтобы некоторые сценарии управлялись с помощью virtualenv в iCloud, сталкивается с этой проблемой.

Было бы полезно, если бы стойкие, хорошо знающие virtualenv, предложили многообещающие подходы.

Что ж, если бы мы знали что-то такое, мы бы, вероятно, не оставили этот вопрос нерешенным так долго, учитывая количество критики, которую мы, похоже, получаем за это :-(

Если бы я хотел вставить предупреждающее сообщение для пользователя, который вводит virtualenv ~ / my \ long \ path \ with \ space, где лучше всего размещать этот код?

Вы можете начать с просмотра кода синтаксического анализа аргументов, добавив проверку после определения пути.

Есть ли в таком патче неочевидные ограничения, которыми могли бы поделиться стойкие, чтобы убрать препятствие для посетителя, работающего над своим первым вкладом?

Они в большинстве случаев могут быть найдены путем поиска списка проблем здесь различных замечаний , сделанных по этому и другим вопросам , на протяжении многих лет, но начать с того , что вам нужно не отказываться от пути , когда они будут работать - и это означает , что работает, какие ограничения ОС накладывает. Они сильно различаются между системами. Windows допускает пробелы и длинные имена файлов, некоторые системы Unix допускают пробелы, некоторым нужны пути с пробелами для цитирования, некоторые имеют очень короткие ограничения длины (32 символа?), Некоторые длиннее, ... Многие ограничения плохо документированы, и очень мало участники имеют доступ к достаточному количеству систем, чтобы иметь возможность протестировать все возможности, достаточные для дополнения доступной документации.

Есть ли у стойких приверженцев какие-то исторические возражения против принятия такого патча?

Нет, кроме как «не думайте, что это так просто, как вы думаете на первый взгляд, и не игнорируйте все различные (иногда довольно неясные) системы, которые мы должны поддерживать».

Если кто-то действительно хочет нанести удар по этому вопросу - и они должны знать, что это не то, что я лично рекомендовал бы в качестве «первого вклада», - тогда им следует начать с чтения всей истории, доступной в различных выпусках (некоторые связаны с этим, другие, вероятно, нет, некоторые, вероятно, на трекере pip и, возможно, даже в трекерах distlib или setuptools) и суммируют в новом PR ограничения, налагаемые различными ОС. Предложите в качестве исправления документации, что «если эти условия не выполняются, заголовки shebang, используемые virtualenv, не будут работать должным образом, и поэтому virtualenv не поддерживает создание сред в каталогах, которые не соответствуют заявленным условиям». PR может включать изменение кода, чтобы предупредить, если задокументированные условия не соблюдены, или может предлагать это в качестве будущей работы (насколько я помню, довольно сложно проанализировать детали системы достаточно точно, чтобы знать, какие ограничения применяются - подумайте о "Ubuntu с пропатченным ядром "...). Лично я был бы в порядке с предупреждением, в котором отмечены только известные случаи, когда что-то выходило из строя, и молчал, если он не был уверен. Но на этом этапе я бы также согласился с патчем только для документов.

Затем вам нужно будет получить отзывы о своем патче от людей, имеющих доступ к системам, которые вы покрываете - как уже отмечалось, основные разработчики здесь не могут помочь, потому что никто из нас не использует (например) FreeBSD, OpenBSD или Solaris, или же ...

Вы также можете просто выполнить частичную работу и создать PR, который добавлял документы и предупреждение только (скажем) для OSX. Я не знаю, остановит ли это жалобы на эту проблему (я не знаю, в каких системах это чаще всего возникает), но, возможно, этого будет достаточно. Возможно, один из основных разработчиков, использующих OSX, согласится с этим.

Это поможет?

Возможно, я чего-то не понимаю, но нельзя ли решить эту проблему, если (например) bin/pip содержит

#!/bin/sh
"/my/long path/with spaces/pythonx.y" "/path/to/my project/with spaces/venv/bin/real-pip" "$@"

а затем переместить текущий сценарий pip в real-pip ? Я не понимаю, почему мы должны использовать shebang напрямую.

@ raxod502 Я полагаю, вы знаете, что это не сработает в Windows. Кроме того, я думаю, что «нормальное» заклинание, необходимое во второй строке, более сложно, чем то, которое вы даете (хотя лично я не знаю почему). Вероятно, вы сможете найти правильный подход через поиск в Интернете. Что произойдет при вашем подходе с путями, содержащими символы " или $ ?

Предполагая, что вы можете решить такие проблемы, я думаю, что следующим шагом будет для вас отправка PR (согласно комментариям выше), и мы сможем обсудить особенности этого. Вам нужно будет привлечь хотя бы одного из основных коммиттеров virtualenv, которые работают с Unix - как пользователь Windows я бы не хотел сам объединять PR, специфичный для Unix.

@pfmoore
Предлагаемое решение @ raxod502 может также работать в Windows с файлом сценария .bat, afaik?

@gst Короткий ответ, нет. Подробный ответ на http://paul-moores-notes.readthedocs.io/en/latest/wrappers.html На протяжении многих лет по этому поводу велось много дискуссий, и каждый раз, когда кто-то предлагал решение, отличное от Обертка exe, у нее проблемы.

В этом случае помните, что этой проблемы не существует в Windows . Таким образом, нет абсолютно никаких причин менять что-либо в среде Windows - любое изменение должно быть ограничено только Unix.

спасибо за хороший ответ :)

кроме оболочки exe, у нее были проблемы.

лично я могу с этим жить (если бы пришлось).

Я обновил distlib чтобы обрабатывать длинные пути и пути с пробелами. Я не использовал патч Харальда Нордгрена напрямую (у него были некоторые проблемы - например, не было тестов), но подход тот же - использование / bin / sh в качестве исполняемого файла. pip / virtualenv Сопровождающие могут захотеть протестировать после локальной продажи текущей версии репозитория distlib .

Версия pip для разработки теперь предоставляет эту новую версию distlib, что означает, что pip теперь отлично обрабатывает пробелы в именах каталогов.

Насколько я понимаю, как только будет выпущен следующий выпуск pip и выпуск virtualenv, эта проблема будет исправлена ​​- любой новый созданный virtualenv будет поддерживать пробелы в пути, как и двоичные файлы, установленные с помощью pip (за исключением, возможно, некоторых необычных случаев, таких как setuptools 'обертки, которые не устанавливаются непосредственно pip).

Я только начал использовать gvfs для монтирования общих ресурсов samba в пользовательском пространстве и обнаружил, что virtualenv / pip и т. Д. Заблокированы из-за точки в путях монтирования, созданных gvfs.

В путях нет пробелов, но есть много других вещей, чтобы поставить virtualenv / pip и т. Д. На колени, пытаясь запустить в директории вроде

/run/user/1000/gvfs/smb-share:server=bolt,share=eng/projects/msp/mrfbus/land

Насколько я понимаю, в настоящее время в gvfs нет опции для предотвращения знаков препинания в путях сгенерированных точек монтирования. Мой единственный обходной путь - никогда не создавать virtualenv на монтировании gvfs, что кажется немного печальным.

@pradyunsg Есть какие-то сроки для следующего выпуска pip? Последнее было более года назад , и кажется глупым так долго ждать, пока это действительно простое исправление не появится в virtualenv.

Привет @ raxod502!

Да, мы хотим его скоро выпустить. Дело в том, что у разработчиков мало времени, чтобы выпустить PEP 518, что мы и хотим сделать. Может случиться так, что есть пункт 10 без PEP 518, но опять же, это зависит от того, найдется ли время, чтобы согласовать этот план.

Похоже, что эта ошибка исправлена pip 10.0.0 , выпущенным 2018-04-14. Строго говоря, исправление было в distlib 0.2.6 , которое было поставлено в pip вместе с их PR4819 в октябре 2017 года, впервые появившимся в pip 10.0.0b2.

Основное исправление, по-видимому, находится в коммите 9285cca distlib . Как прокомментировал vsajip 28 мая 2017 г. , подход следует идее Харальда Нордгрена: продолжать использовать простой shebang для простых случаев (ОС - это не Posix, или путь достаточно короткий и без пробелов), но для непростых случаев используйте вместо этого используйте команду /bin/sh exec , которая может обрабатывать длинные пути или пути, содержащие пробелы.

Я провел быстрый тест в Mac OS X 10.11.6, создав виртуальный env по длинному пути с пробелами в нем, затем вызвав pip3 install , и, похоже, это сработало. Я не полностью проверил, что все, что описано в этой ошибке, исправлено в каждой ОС.

После обновления pip с 9.0.1 до 18.1 (они перешли на версию на основе календаря) и virtualenv с 15.0.1 до 16.0.0 с использованием Ubuntu 16.04.5 LTS проблема, похоже, исчезла:

sudo pip install --upgrade pip
sudo pip install --upgrade virtualenv

Теперь все команды pip корректно работают в виртуальных библиотеках с пробелами в корневом пути.

Как подтвердили @JLDH и @gandie , эта проблема теперь решена; с последними версиями pip и virtualenv, которые вместе работают правильно, когда в корне virtualenv есть пробелы.

Закрытие этого! Спасибо за работу над исправлением @vsajip!

Старый билет: а почему бы и нет

! / usr / bin / env python?

@rirl , думаю, комментарий к закрытой