In message <32c162ba-03f6-40f9-f5d0-d23fde144716@priesch.co.at>,
Marcus Priesch writes:
>>>>           while tail != 'lib' and head != '':
>>>>               head, tail = os.path.split(head)
>
>I really dont know what you are trying to achieve with this piece of
>code, but shouldnt there be a more general approach to get there?
>
>i am pretty sure that other python packagers have the same problem and
>it is already solved somehow ? or am i wrong ?

It isn't solved, it's generally not a problem for them. Here is the
issue. Roundup includes man pages, templates and locale files. Normal
pip installations put all of that under the site-packages directory
(i.e. in platlib). Needless to say, man roundup-server wil not
work. Looking for templates means searching not in
/usr/share/roundup/templates, but in

  /usr/(lib|lib64)/python<version mumble>/site-packages/<sys.prefix>/share/roundup/templates

ugh. Also if you are looking for the locale files (so you can fix them
by undumping the .mo file), don't go to /usr/share/locale bacause they
won't be there.

Most pypi packages don't have this supporting material. So for them
this is a non-existant problem.

In setup.py, the execuables can be specified by defining
entry_points. Then pip creates stubs in /ur/bin or equivalent so the
commands can be run. There is nothing for these other types (man
pages, locale ...) of files.

That being said, Sunday I committed a second pass at allowing roundup
to find it's supporting fles under site-packages/<sys.prefix> commit
5ad7fb912227. But humans who want to use those files are still poorly
served. (Btw the current mechanism is the fix for a bug when somebody
as trying to look at how something was done in one of the templates.)

>why do you need to access anything above "platlib" ?

Because that is one way to determine where these other files should be
placed outside of the platform library. The function itself has a doc
string of:

   Get site specific prefix using --prefix, platform lib or
   sys.prefix.

>>>>>> get_path("platlib")
>>> '/home/pr/work/projects/5t-roundup/ve2/lib64/python2.7/site-packages'
>
>... doesnt it always end with .../pythonX.X/site-packages ?

One would hope so. I have no spec that says that is the case.  Also
--lib-prefix I think can override that (but the current heuristic
would probably fail as well). I seem to remember being very surprised
with a python2 pip installing stuff into dist-packages rather than
site-packages 8-/.

Looking for 'lib' is most definately a (bad) hack.

>then you could just strip the last two dirs to get there ...

I wonder if stripping the tail directory and looking for a 'share'
subdirectory would work better? Using the existence of a share
subdirectory as a marker seems problematic, but the current mechanism
isn't much better.

>ps: i worked on roundup with ralf about 15 years ago, but rarely used it
>in between ... and now i am back for some project we are working on
>together ;)

Welcome back. The more the merrier.