1 |
Hello, all. |
2 |
|
3 |
Currently we've inherited the script naming scheme used by |
4 |
python.eclass, then modified by python-distutils-ng and then modified |
5 |
again by us. However, this has a few disadvantages. |
6 |
|
7 |
The scripts are named like: |
8 |
|
9 |
/usr/bin/foo-pythonX.Y |
10 |
|
11 |
and a wrapper is installed in /usr/bin/foo. |
12 |
|
13 |
Advantages: |
14 |
|
15 |
- easy access to every variant (in $PATH). |
16 |
|
17 |
Disadvantages: |
18 |
|
19 |
- tab completion polluted with all those variants, |
20 |
|
21 |
- argv[0] changed which makes some software unhappy. |
22 |
|
23 |
|
24 |
As a quick idea, here's an alternative: |
25 |
|
26 |
/usr/lib/python-scripts/pythonX.Y/foo |
27 |
|
28 |
(or something similar, path needs to be discussed) |
29 |
|
30 |
Advantages: |
31 |
|
32 |
- wrapper could be mostly 'replaced' by placing those dirs in $PATH, |
33 |
in specific order, |
34 |
|
35 |
- we can let user decide on *exact* order of implementation preference |
36 |
without making code complex, |
37 |
|
38 |
- basename(argv[0]) is preserved. |
39 |
|
40 |
Disadvantages: |
41 |
|
42 |
- handling locations outside standard $PATH locations could result in |
43 |
'deep' directory structure (do we have any?), |
44 |
|
45 |
- potential $PATH pollution (6-8 paths in the 'worst' case). Do modern |
46 |
systems have any trouble with that? |
47 |
|
48 |
- harder to choose a specific implementation. 'foo-python2.7' nor |
49 |
'EPYTHON=python2.7' would work anymore. You'd need to pass the full |
50 |
path, |
51 |
|
52 |
- we will probably still need the wrapper in /usr/bin because of |
53 |
software that doesn't do $PATH lookups. |
54 |
|
55 |
|
56 |
I feel like the second idea is the way forward. Though for implementing |
57 |
it we will probably need to either kill off python.eclass for good, or |
58 |
patch it to support the new way. Supporting it in python-r1 is pretty |
59 |
straightforward. |
60 |
|
61 |
-- |
62 |
Best regards, |
63 |
Michał Górny |