naming of python scripts ...

[Peter Danecek]

On 31 Mar 2014, at 02:54, Ryan Schmidt <ryandesign at macports.org> wrote:

> 
> On Mar 28, 2014, at 12:00, Peter Danecek wrote:
> 
>> I am realising, that some python packages which also install scripts in `bin` provide also version dependent names. For example py27-coverage (which I am looking at) is providing apart from `coverage` also `coverage2` and `coverage-2.7`. 
>> 
>> In combination with Macports Portgroup which places these scripts end in /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/ and links with version postfix are created. This leads to quite weird names link;
>> 
>> - coverage-2.7
>> - coverage2-2.7
>> - coverage-2.7-27
> 
> Yup, that’s weird and should be fixed.

I already fixed this particular port by avoiding that the extra scripts are created, see #43105. There will be no `coverage2` script. This would require to have default versions for python 2.x and 3.x and I do not see any way to support this with the current select mechanism. But I guess this is not a big deal. 

>> So wouldn't it be decidable that the Portgroup removes these additional scripts (only differing by a version postfix before the links are created?
> 
> Previously, it’s been up to each port to fix such problems. How do you propose the portgroup would fix it automatically? I’m not sure how the portgroup could know all the weird naming permutations that a module author might decide to use.

Well, if this is the preferred strategy that's fine. But this probably requires several ports to be fixed. I saw similar names before (ipython?). Will try to assess how often this issue appears.

For a possible strategy, a vague idea was to delete scripts with names like (but I admit I am not very fluent in TCL and with PortGroups):

*-${python_version_major}.${python_version_major} 
*-${python_version_major}${python_version_major} 
*-$${python_version_major}

*${python_version_major}.${python_version_major} 
*${python_version_major}${python_version_major} 
*$${python_version_major}

... after destroot and before the symlinks are created.

The names are guesses, but it should be relatively safe to remove. Alternatively one just would specify the scripts to remove explicitly, but they would be removed BEFORE the symlinks are created. 

~petr




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1762 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140331/e324dede/attachment.p7s>