%%PYTHON_SITELIBDIR%% in pkg-plist

[Nikolai Lifanov]

On 2013-07-06 11:54, Bryan Drewery wrote:
> On 7/6/2013 10:43 AM, Kubilay Kocak wrote:
>> On 7/07/2013 12:51 AM, Nikolai Lifanov wrote:
>>> Hello.
>>> 
>>> I maintain sysutils/ansible, and I keep wanting to @dirrmtry
>>> %%PYTHON_SITELIBDIR%% and perhaps %%PYTHON_LIBDIR%%.
>>> portlint tells me that this is a wrong thing to do, while poudriere
>>> testport complains about leftover directories.
>>> 
>>> What is the correct thing to do with these?
>>> 
>>> - Nikolai Lifanov
>>> 
>>> _______________________________________________
>>> freebsd-ports at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>>> To unsubscribe, send any mail to 
>>> "freebsd-ports-unsubscribe at freebsd.org"
>> 
>> The following are 'normal'leftover entries when testing python ports,
>> and can safely be ignored:
>> 
>> %%PYTHON_LIBDIR%%/site-packages/easy-install.pth
>> %%PYTHON_LIBDIR%%/site-packages/site.py
>> %%PYTHON_LIBDIR%%/site-packages/site.pyc
>> %%PYTHON_LIBDIR%%/site-packages/site.pyo
>> @dirrm %%PYTHON_LIBDIR%%/site-packages
>> @dirrm %%PYTHON_LIBDIR%%
>> 
>> The above output is from poudriere, and 
>> %%PYTHON_LIBDIR%%/site-packages/
>> is actually %%PYTHON_SITELIBDIR%%. Here, poudriere is just making a
>> first-variable-from-the-list-wins guess.
>> 
>> If you see porttools `port test` output, you'll note it displays
>> %%PYTHON_SITELIBDIR%% as the leftover prefix. They can be ignored as 
>> well.
>> 
>> Hope that helps :)
>> 
> 
> The problem is just that the port (and python ports) do not respect
> PREFIX when it does not equal LOCALBASE. By default, 'poudriere
> testport' uses a custom PREFIX. In general, ports should pass leftover
> tests by default. If they use ports framework support that does not
> respect PREFIX, try using -n as well, which will stick to
> PREFIX=LOCALBASE. In this case, using -n passes the test with testport
> on ansible.

Hmm... This works and makes sense, since python sys.prefix is set 
depending on its location.
I might be naive here, but what would be the effect of depending on 
virtualenv magic if PREFIX != LOCALBASE? This way a package can ask for 
dependencies with the same PREFIX if they would otherwise exist 
somewhere else during a single make, and it shouldn't conflict with 
anything else. This can go into a package name 
(py27-non_localbase_prefix_with_encoded_slashes-mypackage) or, after 
pkg_* tools are out, a pkgng annotation?
For example, if py27-foo depends on py27-bar, py27-opt_baz-foo would 
depend on py27-opt_baz-bar without conflicting.

- Nikolai Lifanov