p5 modules, get me started on one

[Scott Haneda]

On Jan 22, 2009, at 5:15 PM, Ryan Schmidt wrote:
> On Jan 21, 2009, at 05:00, Scott Haneda wrote:
>
>>>> List it in the port description?  Will that get searched?  How do  
>>>> I even
>>>> get a list of what is in these packages from the CPAN site?
>>>
>> Seems an ok way to deal with it, not ideal to me though.  I am not  
>> sure if this problem is just perl module related, or is more  
>> generic.  If it would be appropriate, the idea of adding a new  
>> variable to port files may be a fair idea.
>>
>> file_contains or whatever is appropriate, which could then be  
>> searched on by default.  It seems very common that this comes up.
>
> Please no new variable. It uglies up the port. When reading the  
> portfile, I want to be able to concentrate on reading the portfile,  
> not wading through a list of files I don't care about. The ncursesw  
> portfile is currently 38 lines long but it installs 3311 files; I  
> don't want the portfile to grow 3311 lines longer.

Is there any official guidance on this matter?  I am making perl  
module ports, and I generally go to CPAN, copy the title, and use that  
as the short desc, and for the long desc, I use their main  
description.  This can be long at times, is that not recommended?

>>> Also, knowing that Net::SMTP is with the base perl5.8 port is  
>>> something I
>>> just knew because it's part of the perl libnet stuff which was  
>>> integrated
>>> into perl core some time ago.
>
> [snip]
>
>> The question of "How does a new user know that Net::SMTP is part of  
>> the base?" is a problem.
>
> A MacPorts *user* does not need to know that; they just need to know  
> what port they ultimately want to install, and install it.

And I think I am a good case in which that sort of failed me. I needed  
Net::SMTP, but to me, as a user, it was not there.  I tried port list  
p5-net-smtp, and nothing.

This brings up a point, why was the naming convention changed?  It  
took me a while to even learn to prepend p5 and convert :: to -

Next, I tried `port search p5-net-smtp*` and I beleive, I got back p5- 
net-smtp-auth or close to it.  So still no match. Try as I might, I  
could not locate it, so I made my own portfile.  It was then, I found  
out, it was included in another higher up module.

For some reason, I skipped looking for that module, and tried to make  
a port for it, only to learn it was there. Good to learn it was there,  
so I could not take any more time on that one.

But, your statement of "... *user* does not need to know that ... "  
does not ring entirely true for me.  I had a list of modules I needed,  
90% of them did not immediately appear to be available.  In the end,  
about 50% of them were, but it was hard to locate them.

What if every perl module had a port file, and all it was was a port  
file that had a dependency back to the parent module that it is a part  
of?  Then search would find what it needed to, other port files would  
not get dirty with lists of included modules.

> A MacPorts *maintainer* (of perl modules) does perhaps need to know  
> that. But I think it's a matter of knowing your corner of the world.  
> If you're interested in writing perl modules, you need to know a few  
> things about perl, like that it includes a small number of modules;  
> once you know that, you can use "port contents perl5.8" to see what  
> modules are included.

I understand now, though I am still not sure I agree. I can manage,  
and don't get me wrong, I love this system and really commend you guys  
on your mailing list support, so I am not complaining at all.

This probably only applies to perl modules, and maybe some php modules  
or ruby gems.  At any rate, if I need foo::bar::baz I should be able  
to `port search p5-foo-bar-baz` and get something in the case it is  
part of some larger module package.

I would really like to know the history of why I can not `port install  
foo::bar::baz if even only an internal remap to use the standard ::  
notation.  Is this a tcl collision of some sort?

I sort of like the idea of a port file being a pointer to download  
some other package that contains the parent modules, unless someone  
tells me it is a really bad idea.

Thanks for the dialogue.
--
Scott