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-po...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to
"freebsd-ports-unsubscr...@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
_______________________________________________
freebsd-python@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-python
To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
