[devel] python module provides

[devel] python module provides

[Alexey Morsov]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

Приветствую,

а как можно сказать гирару что вот "этот пакет провайдит вот такой модуль
теперь"?

Я тут просто пересобрал PIL по багу (вынес .pth из -devel и внес в
основной) но гирар не пропустил по причине new unmets.


-- 
WBR,Алексей Морсов
программист ЗАО "ИК "Риком-Траст"
Jabber: samurai@www.fondmarket.ru
ALT Linux Team Member

<Voins> посади дебианщика за alt так он сразу локали сломает! :)))

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [devel] python module provides

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

On Sat, Jun 06, 2009 at 06:17:10PM +0400, Alexey Morsov wrote:
> а как можно сказать гирару что вот "этот пакет провайдит вот такой модуль
> теперь"?

Нет, это неправильная постановка задачи: если вам удастся обмануть
сборочную систему, и кривой пакет попадёт в Сизиф, то он просто сломает
пакеты, которые на него завязаны.

> Я тут просто пересобрал PIL по багу (вынес .pth из -devel и внес в
> основной) но гирар не пропустил по причине new unmets.

Значит, вы что-то не то или не так делаете.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] python module provides

[Alexey Morsov]

[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]

On Sat, Jun 06, 2009 at 08:18:15PM +0400, Dmitry V. Levin wrote:
> Нет, это неправильная постановка задачи: если вам удастся обмануть
> сборочную систему, и кривой пакет попадёт в Сизиф, то он просто сломает
> пакеты, которые на него завязаны.
Возможно.

> 
> > Я тут просто пересобрал PIL по багу (вынес .pth из -devel и внес в
> > основной) но гирар не пропустил по причине new unmets.
> 
> Значит, вы что-то не то или не так делаете.
Ну по сути. Сейчас python-module-imaging-devel содержит файл PIL.pth.
Из-за этого допустим при инсталяции uniconverter тянется именно -devel а
не сам пакет.

тут https://bugzilla.altlinux.org/show_bug.cgi?id=18529 предложено
перенести PIL.pth в сам пакет исключив его из -devel.

спек можно видеть в моем гите.

Собственно как я представляю ситуацию и то почему гирар меня отлупил по
анметам: в некоторых пакетах (бинарных) есть (автоматическая?) зависимость на того кто предоставляет python(PIL). До сего момента выходило что его предоставлял -devel (поскольку в нем PIL.pth).
Т.е. либо в тех пакетах надо напрямую указывать что они требуют именно
python-module-imaging (что наверное не очень сейчас правильно), либо
каким-то образом указать что теперь python-module-imaging (не -devel)
предоставялет то самый python(PIL). 

На моей локальной машине теперь при apt-get install uniconverter тянется
именно python-module-imaging, а не девел, как до пересборки.

-- 
WBR,Алексей Морсов
программист ЗАО "ИК "Риком-Траст"
Jabber: samurai@www.fondmarket.ru
ALT Linux Team Member

Я опять изобрел велосипед. [...] Но данный конкретные велосипед работает
очень хорошо, гораздо лучше предыдущих.
		-- at in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [devel] python module provides

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

On Sun, Jun 07, 2009 at 02:22:25PM +0400, Alexey Morsov wrote:
> On Sat, Jun 06, 2009 at 08:18:15PM +0400, Dmitry V. Levin wrote:
[...]
> > > Я тут просто пересобрал PIL по багу (вынес .pth из -devel и внес в
> > > основной) но гирар не пропустил по причине new unmets.
> > 
> > Значит, вы что-то не то или не так делаете.
> Ну по сути. Сейчас python-module-imaging-devel содержит файл PIL.pth.
> Из-за этого допустим при инсталяции uniconverter тянется именно -devel а
> не сам пакет.
> 
> тут https://bugzilla.altlinux.org/show_bug.cgi?id=18529 предложено
> перенести PIL.pth в сам пакет исключив его из -devel.
> 
> спек можно видеть в моем гите.

Если просто пересобрать нынешний python-module-imaging-1.1.6-alt2.src.rpm
в текущей среде, то полученный бинарный python-module-imaging теряет
python2.5(PIL) и python2.5(PIL.*) из своих Provides.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] python module provides

[Alexey Morsov]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On Sun, Jun 07, 2009 at 02:52:40PM +0400, Dmitry V. Levin wrote:

> Если просто пересобрать нынешний python-module-imaging-1.1.6-alt2.src.rpm
> в текущей среде, то полученный бинарный python-module-imaging теряет
> python2.5(PIL) и python2.5(PIL.*) из своих Provides.

Ну... таки баг и таки не просто так alt3 ?

-- 
WBR,Алексей Морсов
программист ЗАО "ИК "Риком-Траст"
Jabber: samurai@www.fondmarket.ru
ALT Linux Team Member

> Как всем этим воспользоваться?
В каких смыслах? Можно на лобовуху в машине повесить, можно в соседа
метнуть. Можно в сидюк вставить и с него загрузиться...
		-- vyt in community@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [devel] python module provides

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

On Sun, Jun 07, 2009 at 04:24:30PM +0400, Alexey Morsov wrote:
> On Sun, Jun 07, 2009 at 02:52:40PM +0400, Dmitry V. Levin wrote:
> 
> > Если просто пересобрать нынешний python-module-imaging-1.1.6-alt2.src.rpm
> > в текущей среде, то полученный бинарный python-module-imaging теряет
> > python2.5(PIL) и python2.5(PIL.*) из своих Provides.
> 
> Ну... таки баг и таки не просто так alt3 ?

В alt3 ситуация аналогичная: нет python2.5(PIL) и python2.5(PIL.*).


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] python module provides

[Terechkov Evgenii]

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

07.06.2009 Dmitry V. Levin писал:

> > > Если просто пересобрать нынешний python-module-imaging-1.1.6-alt2.src.rpm
> > > в текущей среде, то полученный бинарный python-module-imaging теряет
> > > python2.5(PIL) и python2.5(PIL.*) из своих Provides.
> > Ну... таки баг и таки не просто так alt3 ?
> В alt3 ситуация аналогичная: нет python2.5(PIL) и python2.5(PIL.*).

Судя по коммитам, переход alt2 -> alt3 сделан корректно, перенесением
файла PIL.pth из одного подпакета в другой.

Пересборка python-module-imaging-1.1.6-alt3 в среде с
rpm-build-python-0.33.2-alt1 даёт Provides: python2.5(PIL),
python2.5(PIL.*) в подпакете python-module-imaging. Я думаю, это
регрессия в rpm-build-python.

-- 
                                                С уважением, Терешков
                                                Евгений, ALT Linux
                                                Team

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] rpm-build-python-0.34-alt1 regression

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

On Sun, Jun 07, 2009 at 11:25:24PM +0800, Terechkov Evgenii wrote:
> 07.06.2009 Dmitry V. Levin писал:
> 
> > > > Если просто пересобрать нынешний python-module-imaging-1.1.6-alt2.src.rpm
> > > > в текущей среде, то полученный бинарный python-module-imaging теряет
> > > > python2.5(PIL) и python2.5(PIL.*) из своих Provides.
> > > Ну... таки баг и таки не просто так alt3 ?
> > В alt3 ситуация аналогичная: нет python2.5(PIL) и python2.5(PIL.*).
> 
> Судя по коммитам, переход alt2 -> alt3 сделан корректно, перенесением
> файла PIL.pth из одного подпакета в другой.

Да, вполне.

> Пересборка python-module-imaging-1.1.6-alt3 в среде с
> rpm-build-python-0.33.2-alt1 даёт Provides: python2.5(PIL),
> python2.5(PIL.*) в подпакете python-module-imaging. Я думаю, это
> регрессия в rpm-build-python.

Да, вполне возможно.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] rpm-build-python-0.34-alt1 regression

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

On Sun, Jun 07, 2009 at 08:41:53PM +0400, Dmitry V. Levin wrote:
> On Sun, Jun 07, 2009 at 11:25:24PM +0800, Terechkov Evgenii wrote:
> > 07.06.2009 Dmitry V. Levin писал:
> > 
> > > > > Если просто пересобрать нынешний python-module-imaging-1.1.6-alt2.src.rpm
> > > > > в текущей среде, то полученный бинарный python-module-imaging теряет
> > > > > python2.5(PIL) и python2.5(PIL.*) из своих Provides.
> > > > Ну... таки баг и таки не просто так alt3 ?
> > > В alt3 ситуация аналогичная: нет python2.5(PIL) и python2.5(PIL.*).
> > 
> > Судя по коммитам, переход alt2 -> alt3 сделан корректно, перенесением
> > файла PIL.pth из одного подпакета в другой.
> 
> Да, вполне.
> 
> > Пересборка python-module-imaging-1.1.6-alt3 в среде с
> > rpm-build-python-0.33.2-alt1 даёт Provides: python2.5(PIL),
> > python2.5(PIL.*) в подпакете python-module-imaging. Я думаю, это
> > регрессия в rpm-build-python.
> 
> Да, вполне возможно.

Уважаемые мужички!
Я посмотрел эту проблему, но пока проблемы особо не понял.

$ hsh-install 'python2.5(PIL)'
<13>Jun  8 07:25:23 rpmi: python-module-imaging-devel-1.1.6-alt2 installed
$ hsh-run -- python -c 'import PIL'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named PIL
$ 

Пространство питоновских зависимостей -- это имена модулей, которые
могут быть импортированы с помощью инструкции import.

Другими словами, если пакет предоставляет зависимость 'python(foo)',
то это должно значить, что будет работать команда python -c 'import foo'.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] rpm-build-python-0.34-alt1 regression

[Terechkov Evgenii]

[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]

08.06.2009 Alexey Tourbin писал:

> > > > > > Если просто пересобрать нынешний python-module-imaging-1.1.6-alt2.src.rpm
> > > > > > в текущей среде, то полученный бинарный python-module-imaging теряет
> > > > > > python2.5(PIL) и python2.5(PIL.*) из своих Provides.
> > > > > Ну... таки баг и таки не просто так alt3 ?
> > > > В alt3 ситуация аналогичная: нет python2.5(PIL) и python2.5(PIL.*).
> > > Судя по коммитам, переход alt2 -> alt3 сделан корректно, перенесением
> > > файла PIL.pth из одного подпакета в другой.
> > Да, вполне.
> > > Пересборка python-module-imaging-1.1.6-alt3 в среде с
> > > rpm-build-python-0.33.2-alt1 даёт Provides: python2.5(PIL),
> > > python2.5(PIL.*) в подпакете python-module-imaging. Я думаю, это
> > > регрессия в rpm-build-python.
> Я посмотрел эту проблему, но пока проблемы особо не понял.
> $ hsh-install 'python2.5(PIL)'
> <13>Jun  8 07:25:23 rpmi: python-module-imaging-devel-1.1.6-alt2 installed
> $ hsh-run -- python -c 'import PIL'
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
> ImportError: No module named PIL
> $ 
> Пространство питоновских зависимостей -- это имена модулей, которые
> могут быть импортированы с помощью инструкции import.
> Другими словами, если пакет предоставляет зависимость 'python(foo)',
> то это должно значить, что будет работать команда python -c 'import foo'.

Это ошибка в пакете python-module-imaging: файл PIL.pth упакован в
подпакет devel. Эту ошибку swi@ пытается починить сборкой alt3. Но
натыкается на то, что пакет, содержащий и файл PIL.pth и
соответствующую директорию site-packages/PIL/ (т.е. где python -c
"import PIL" должно уже работать) таковую зависимость не предоставяет.

И это уже вторая ошибка. Я так понимаю, что сборка alt2 python2.5(PIL)
предоставляла т.к. была собрана в среде с
rpm-build-python-0.33.2-alt1. Для проверки я пересобрал
python-module-imaging-1.1.6-alt3 в среде с
rpm-build-python-0.33.2-alt1 (вместо 0.34... в Сизифе), в результате
чего python2.5(PIL) стал провайдится пакетом python-module-imaging.

Судя по changelog-у 0.33.2->0.34, была пройзведена переписка кода
python.prov.py, так что я предполагаю что в результате этого действия
Provides: теперь корректно выставлены не у всех питон-пакетов в Сизифе
(точнее у некоторых, собранных с rpm-build-python-0.34). Код изменения
я пока не смотрел.

Кроме того, хотелось бы, чтобы при сборке пакетов проверялось, реально
ли пакет, содержащий *.pth-файл, может обеспечить python -c "import
foo", чтобы застраховаться от подобный ошибок упаковки.

-- 
                                                С уважением, Терешков
                                                Евгений, ALT Linux
                                                Team

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] rpm-build-python-0.34-alt1 regression

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3447 bytes --]

On Mon, Jun 08, 2009 at 06:41:36PM +0800, Terechkov Evgenii wrote:
> > > > Пересборка python-module-imaging-1.1.6-alt3 в среде с
> > > > rpm-build-python-0.33.2-alt1 даёт Provides: python2.5(PIL),
> > > > python2.5(PIL.*) в подпакете python-module-imaging. Я думаю, это
> > > > регрессия в rpm-build-python.
> > Я посмотрел эту проблему, но пока проблемы особо не понял.
> > $ hsh-install 'python2.5(PIL)'
> > <13>Jun  8 07:25:23 rpmi: python-module-imaging-devel-1.1.6-alt2 installed
> > $ hsh-run -- python -c 'import PIL'
> > Traceback (most recent call last):
> >   File "<string>", line 1, in <module>
> > ImportError: No module named PIL
> > $ 
> > Пространство питоновских зависимостей -- это имена модулей, которые
> > могут быть импортированы с помощью инструкции import.
> > Другими словами, если пакет предоставляет зависимость 'python(foo)',
> > то это должно значить, что будет работать команда python -c 'import foo'.
> 
> Это ошибка в пакете python-module-imaging: файл PIL.pth упакован в
> подпакет devel. Эту ошибку swi@ пытается починить сборкой alt3. Но
> натыкается на то, что пакет, содержащий и файл PIL.pth и
> соответствующую директорию site-packages/PIL/ (т.е. где python -c
> "import PIL" должно уже работать) таковую зависимость не предоставяет.
> 
> И это уже вторая ошибка. Я так понимаю, что сборка alt2 python2.5(PIL)
> предоставляла т.к. была собрана в среде с
> rpm-build-python-0.33.2-alt1. Для проверки я пересобрал
> python-module-imaging-1.1.6-alt3 в среде с
> rpm-build-python-0.33.2-alt1 (вместо 0.34... в Сизифе), в результате
> чего python2.5(PIL) стал провайдится пакетом python-module-imaging.
> 
> Судя по changelog-у 0.33.2->0.34, была пройзведена переписка кода
> python.prov.py, так что я предполагаю что в результате этого действия
> Provides: теперь корректно выставлены не у всех питон-пакетов в Сизифе
> (точнее у некоторых, собранных с rpm-build-python-0.34). Код изменения
> я пока не смотрел.

Уважаемые мужички!
Давайте рассмотрим конструкцию по делу.

У нас есть несколько файлов:
/usr/lib64/python2.5/site-packages/PIL.pth в нём написано "PIL" и допустим
/usr/lib64/python2.5/site-packages/PIL/__init__.py
/usr/lib64/python2.5/site-packages/PIL/Image.py

В предположении, что каждый файл может предоставлять только один модуль
(то есть в предположении, что PIL/Image.py должен дать только одну
Provides-зависимость в пространстве питоновских модулей) нам нужно
сформировать Provides.  При формировании Provides путь к файлу
разбивается на две компоненты: стандартный каталог и оставшийся путь
к модулю.  Причем стандартный каталог выбирается наиболее длинным,
поскольку, например, site-packages является подкаталогом в стандартном
каталоге.

Так вот, PIL.pth задает в качестве стандартного каталога подкаталог PIL,
и все Provides-зависимости отсчитываются от подкаталога PIL.  То есть
будет что PIL/Image.py предоставляет python2.5(Image).  Новая версия
python.prov.py работает правильно, насколько что по смыслу можно
объяснить как она должна работать.

Возможно, файл PIL.pth вообще не следует упаковывать.  Более того, его
нужно удалить в %buildroot.  Тогда образуются Provides вида python2.5(PIL*).

Примите и проч.

> Кроме того, хотелось бы, чтобы при сборке пакетов проверялось, реально
> ли пакет, содержащий *.pth-файл, может обеспечить python -c "import
> foo", чтобы застраховаться от подобный ошибок упаковки.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] rpm-build-python-0.34-alt1 regression

[Terechkov Evgenii]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

08.06.2009 Alexey Tourbin писал:

> Давайте рассмотрим конструкцию по делу.
> 
> У нас есть несколько файлов:
> /usr/lib64/python2.5/site-packages/PIL.pth в нём написано "PIL" и допустим
> /usr/lib64/python2.5/site-packages/PIL/__init__.py
> /usr/lib64/python2.5/site-packages/PIL/Image.py
> 
> В предположении, что каждый файл может предоставлять только один модуль
> (то есть в предположении, что PIL/Image.py должен дать только одну
> Provides-зависимость в пространстве питоновских модулей) нам нужно
> сформировать Provides.  При формировании Provides путь к файлу
> разбивается на две компоненты: стандартный каталог и оставшийся путь
> к модулю.  Причем стандартный каталог выбирается наиболее длинным,
> поскольку, например, site-packages является подкаталогом в стандартном
> каталоге.
> 
> Так вот, PIL.pth задает в качестве стандартного каталога подкаталог PIL,
> и все Provides-зависимости отсчитываются от подкаталога PIL.  То есть
> будет что PIL/Image.py предоставляет python2.5(Image).  Новая версия
> python.prov.py работает правильно, насколько что по смыслу можно
> объяснить как она должна работать.

Спасибо за объяснение. Виноват - обратил внимание на отсутствие
python2.5(PIL*), но не заметил странных python2.5(Image)

> Возможно, файл PIL.pth вообще не следует упаковывать.  Более того, его
> нужно удалить в %buildroot.  Тогда образуются Provides вида python2.5(PIL*).

Я попробовал пересобрать пакет без этого файла (в т.ч. и в %buildroot)
- Provides остались в том же виде - python2.5(Image). Видимо надо
действовать как-то ещё.

-- 
                                                С уважением, Терешков
                                                Евгений, ALT Linux
                                                Team

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] rpm-build-python-0.34-alt1 regression

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

On Mon, Jun 08, 2009 at 11:19:07PM +0800, Terechkov Evgenii wrote:
> > В предположении, что каждый файл может предоставлять только один модуль
> > (то есть в предположении, что PIL/Image.py должен дать только одну
> > Provides-зависимость в пространстве питоновских модулей) нам нужно
> > сформировать Provides.  При формировании Provides путь к файлу
> > разбивается на две компоненты: стандартный каталог и оставшийся путь
> > к модулю.  Причем стандартный каталог выбирается наиболее длинным,
> > поскольку, например, site-packages является подкаталогом в стандартном
> > каталоге.
> > 
> > Так вот, PIL.pth задает в качестве стандартного каталога подкаталог PIL,
> > и все Provides-зависимости отсчитываются от подкаталога PIL.  То есть
> > будет что PIL/Image.py предоставляет python2.5(Image).  Новая версия
> > python.prov.py работает правильно, насколько что по смыслу можно
> > объяснить как она должна работать.
> 
> Спасибо за объяснение. Виноват - обратил внимание на отсутствие
> python2.5(PIL*), но не заметил странных python2.5(Image)

Надо подумать, как должен работать python.prov.py. :)  Я стал склоняться
к мысли, что действительно имеется регрессия (ухудшение).  Но это тогда
значит, что каждый питоновский модуль может предоставлять более одной
зависимости Provides!  То есть его можно загрузить как Image и как
PIL.Image, и эти формы более-менее равноправны.

В существующем (ранее собранном) пакете как раз предоставляются две эти
зависимости.

$ rpm -qp --provides python-module-imaging-1.1.6-alt2.x86_64.rpm |grep -w Image
python2.5(Image)  
python2.5(PIL.Image)  
$

> > Возможно, файл PIL.pth вообще не следует упаковывать.  Более того, его
> > нужно удалить в %buildroot.  Тогда образуются Provides вида python2.5(PIL*).
> 
> Я попробовал пересобрать пакет без этого файла (в т.ч. и в %buildroot)
> - Provides остались в том же виде - python2.5(Image). Видимо надо
> действовать как-то ещё.

Видимо надо как-то действовать!

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] rpm-build-python-0.34-alt1 regression

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]


Twas brillig at 19:33:54 08.06.2009 UTC+04 when at@altlinux.ru did gyre and gimble:

 AT> Но это тогда значит, что каждый питоновский модуль может
 AT> предоставлять более одной зависимости Provides!  То есть его можно
 AT> загрузить как Image и как PIL.Image, и эти формы более-менее
 AT> равноправны.

Так и есть.

[dottedmag@vertex:~]% python
Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Image
>>> Image.__file__
'/usr/lib/python2.5/site-packages/PIL/Image.pyc'
>>> import PIL.Image
>>> PIL.Image.__file__
'/usr/lib/python2.5/site-packages/PIL/Image.pyc'
>>> 

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 834 bytes --]

Re: [devel] rpm-build-python-0.34-alt1 regression

[Terechkov Evgenii]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

08.06.2009 Mikhail Gusarov писал:

>  AT> Но это тогда значит, что каждый питоновский модуль может
>  AT> предоставлять более одной зависимости Provides!  То есть его можно
>  AT> загрузить как Image и как PIL.Image, и эти формы более-менее
>  AT> равноправны.
> Так и есть.
> [dottedmag@vertex:~]% python
> Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47) 
> [GCC 4.3.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import Image
> >>> Image.__file__
> '/usr/lib/python2.5/site-packages/PIL/Image.pyc'
> >>> import PIL.Image
> >>> PIL.Image.__file__
> '/usr/lib/python2.5/site-packages/PIL/Image.pyc'
> >>> 

Хм. А если я сейчас упакую свой
/usr/lib/python2.5/site-packages/PUL/Image.py + PUL.pth - то какой из
пакетов вытянется тому, что затребует python2.5(Image)?

-- 
                                                С уважением, Терешков
                                                Евгений, ALT Linux
                                                Team

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] rpm-build-python-0.34-alt1 regression

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]


Twas brillig at 23:56:18 08.06.2009 UTC+08 when evg-krsk@yandex.ru did gyre and gimble:

 TE> Хм. А если я сейчас упакую свой
 TE> /usr/lib/python2.5/site-packages/PUL/Image.py + PUL.pth - то какой из
 TE> пакетов вытянется тому, что затребует python2.5(Image)?

[dottedmag@vertex:~]% python
Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Image
>>> Image.__file__
'/usr/lib/python2.5/site-packages/PIL/Image.pyc'

Интересно, почему? Потому, что PIL выше в sys.path:

>>> import sys
>>> sys.path
['', '/home/dottedmag/openinkpot/trac/trac-trunk', '/usr/lib/python2.5/site-packages', '/home/dottedmag/openinkpot/trac/translatedpagesmacro', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages/PIL', '/usr/lib/python2.5/site-packages/PUL', '/usr/lib/python2.5/site-packages/gst-0.10', '/usr/lib/pymodules/python2.5', '/usr/lib/pymodules/python2.5/gtk-2.0', '/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode']
>>> 

Так что надо смотреть внутрь интерпретатора на предмет выяснения, в
каком порядке добавляются в sys.path пути из .pth-файлов.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 834 bytes --]

Re: [devel] rpm-build-python-0.34-alt1 regression

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

On Mon, Jun 08, 2009 at 11:56:18PM +0800, Terechkov Evgenii wrote:
> 08.06.2009 Mikhail Gusarov писал:
> 
> >  AT> Но это тогда значит, что каждый питоновский модуль может
> >  AT> предоставлять более одной зависимости Provides!  То есть его можно
> >  AT> загрузить как Image и как PIL.Image, и эти формы более-менее
> >  AT> равноправны.
> > Так и есть.
> > [dottedmag@vertex:~]% python
> > Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47) 
> > [GCC 4.3.3] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import Image
> > >>> Image.__file__
> > '/usr/lib/python2.5/site-packages/PIL/Image.pyc'
> > >>> import PIL.Image
> > >>> PIL.Image.__file__
> > '/usr/lib/python2.5/site-packages/PIL/Image.pyc'
> > >>> 
> 
> Хм. А если я сейчас упакую свой
> /usr/lib/python2.5/site-packages/PUL/Image.py + PUL.pth - то какой из
> пакетов вытянется тому, что затребует python2.5(Image)?

Зависимости не объясняют, какой пакет должен вытягиваться, они лишь
отражают фактическое положение дел.  Если в коде написано 'import Image'
то должна быть зависимость на python(Image).  А кого надо вытягивать это
совсем другая проблема.  Но, по крайней мере, зависимости должны
обеспечить, что инструкция import не отвалится сразу же с диагностикой
'not found'.

В некотором смысле, зависимости -- это искусство возможного.
Возможное -- это фактическое положнеие дел, что написано в коде.
А невозможное -- это предсказание будущего (спекулятивное выполнение
кода для установления соответствия между именами модулей и файлами
и т.п.).

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] rpm-build-python-0.34-alt1 regression

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2321 bytes --]

On Mon, Jun 08, 2009 at 07:33:54PM +0400, Alexey Tourbin wrote:
> On Mon, Jun 08, 2009 at 11:19:07PM +0800, Terechkov Evgenii wrote:
> > > В предположении, что каждый файл может предоставлять только один модуль
> > > (то есть в предположении, что PIL/Image.py должен дать только одну
> > > Provides-зависимость в пространстве питоновских модулей) нам нужно
> > > сформировать Provides.  При формировании Provides путь к файлу
> > > разбивается на две компоненты: стандартный каталог и оставшийся путь
> > > к модулю.  Причем стандартный каталог выбирается наиболее длинным,
> > > поскольку, например, site-packages является подкаталогом в стандартном
> > > каталоге.
> > > 
> > > Так вот, PIL.pth задает в качестве стандартного каталога подкаталог PIL,
> > > и все Provides-зависимости отсчитываются от подкаталога PIL.  То есть
> > > будет что PIL/Image.py предоставляет python2.5(Image).  Новая версия
> > > python.prov.py работает правильно, насколько что по смыслу можно
> > > объяснить как она должна работать.
> > 
> > Спасибо за объяснение. Виноват - обратил внимание на отсутствие
> > python2.5(PIL*), но не заметил странных python2.5(Image)
> 
> Надо подумать, как должен работать python.prov.py. :)  Я стал склоняться
> к мысли, что действительно имеется регрессия (ухудшение).  Но это тогда
> значит, что каждый питоновский модуль может предоставлять более одной
> зависимости Provides!  То есть его можно загрузить как Image и как
> PIL.Image, и эти формы более-менее равноправны.

В сизиф собрался rpm-build-python 0.34.1.
http://git.altlinux.org/people/at/packages/rpm-build-python.git

* Sat Jun 13 2009 Alexey Tourbin <at@altlinux> 0.34.1-alt2
- rpm-build-python-tools: Disabled python dependencies,
  scheduled for removal.

* Sat Jun 13 2009 Alexey Tourbin <at@altlinux> 0.34.1-alt1
- python.prov.py: Re-added limited support for multpile provides - e.g.
  PIL/Image.py provides both python2.5(PIL.Image) due to PIL/__init__.py
  and python2.5(Image) due to PIL.pth.
- python.prov.py: Do not provide module names with "-" dashes.


> В существующем (ранее собранном) пакете как раз предоставляются две эти
> зависимости.
> 
> $ rpm -qp --provides python-module-imaging-1.1.6-alt2.x86_64.rpm |grep -w Image
> python2.5(Image)  
> python2.5(PIL.Image)  
> $

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] rpm-build-python-0.34-alt1 regression

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 2506 bytes --]

Alexey Tourbin <at-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

> Уважаемые мужички!
> Давайте рассмотрим конструкцию по делу.
>
> У нас есть несколько файлов:
> /usr/lib64/python2.5/site-packages/PIL.pth в нём написано "PIL" и допустим
> /usr/lib64/python2.5/site-packages/PIL/__init__.py
> /usr/lib64/python2.5/site-packages/PIL/Image.py
>
> В предположении, что каждый файл может предоставлять только один модуль
> (то есть в предположении, что PIL/Image.py должен дать только одну
> Provides-зависимость в пространстве питоновских модулей) нам нужно
> сформировать Provides.  При формировании Provides путь к файлу
> разбивается на две компоненты: стандартный каталог и оставшийся путь
> к модулю.  Причем стандартный каталог выбирается наиболее длинным,
> поскольку, например, site-packages является подкаталогом в стандартном
> каталоге.
>
> Так вот, PIL.pth задает в качестве стандартного каталога подкаталог PIL,
> и все Provides-зависимости отсчитываются от подкаталога PIL.  То есть
> будет что PIL/Image.py предоставляет python2.5(Image).  Новая версия
> python.prov.py работает правильно, насколько что по смыслу можно
> объяснить как она должна работать.
>
> Возможно, файл PIL.pth вообще не следует упаковывать.  Более того, его
> нужно удалить в %buildroot.  Тогда образуются Provides вида python2.5(PIL*).
>
> Примите и проч.

В данном случае, PIL вообще очень странная вещь. Они зачем-то
предоставлют и pth и __init__.py. Хотя если подумать, то вещи эти
вобщем-то противоположны.

Но из-за этого некоторые проекты используют PIL по разному. :(

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]