p5 modules, get me started on one

[Scott Haneda]

On Jan 21, 2009, at 1:40 AM, Bryan Blackburn wrote:
> On Tue, Jan 20, 2009 at 05:50:23PM -0800, Scott Haneda said:
>> On Jan 20, 2009, at 5:01 PM, Bryan Blackburn wrote:
> [...]
>>> Some perl modules come packaged in groups like that, which  
>>> definitely
>>> can
>>> cause confusion.  Maybe the best solution would be to list all  
>>> actual
>>> modules installed with the given port?  Then it may be easier to  
>>> search
>>> for
>>> it.
>>
>> 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?
>
> In the long_description is what I was pondering; if you're running  
> MacPorts
> 1.7 'port search' will look in (among other field) long_description by
> default, with trunk you'd need to add the --long_description flag to  
> search
> it.  Anything more specific to perl modules would mean changing base  
> and of
> course deciding first how that would work, etc...

Nice to know, thanks, I was not aware of --long_description

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.

> [...]
>>> The base perl5.8 port should actually have what's in libnet like
>>> Net::SMTP,
>>> so no port should actually be needed for this one.
>>
>>
>> How would I know that?
>> port search smtp
>> All I see is
>> p5-net-smtp_auth @0.08 (perl)
>>    Perl5 SMTP client with AUTHentication
>>
>> If that is it, great, but how would I confirm it is in fact the same
>> thing?  All signs point to it being different.
>
> In many cases, a person running 'port install ...' is probably more
> interested in some final program and not just perl modules, so  
> that's where
> the dependency management comes into play.  This way various port
> maintainers only need to determine the which/where question the one  
> time for
> these things and anyone else just lets port take it from there.

Correct, and the more I think about it, the more I may be looking at  
this wrong.  My end game here is to get ASSP ported.  I need 20 or so  
perl modules to go with it, but once I get those, and build the  
dependency tree in the ASSP port file, no other user will ever care  
about the issues I am currently running into.

> If you're one of those maintainers, then it definitely helps to know  
> the
> software you're dealing with.  In perl's case, what I've done in the  
> past is
> to query search.cpan.org for the specific module, which leads you to  
> either
> a distribution specific to that module or one that includes several  
> modules.

That is exactly where I have been spending my time as well.  To be  
honest, I just wish the developer of ASSP had listed the parent perl  
module rather then the submodule, it would have made this seem a heck  
of a lot easier.

>> From that you'd just create the port and be done with it.
>
> 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.

And that there is the main major problem with this.  While not with  
Net::SMTP, but other perl modules, this bit me.  I need net:foo and  
did not find it, so I made a port.  I later learned net:foo was  
already in net:main so I wasted my time making the port.  In this  
case, these ports are mostly copy and paste, so not a big deal, but it  
could have been a larger waste of time.

This is the main thing I think needs solving, and it sounds like it  
can, with better search, a new field in the port file, and or  
automatic retrieval of some perl module index file that has some  
mappings in it. It may take all those suggestions, I am not sure.

The question of "How does a new user know that Net::SMTP is part of  
the base?" is a problem.

>> Beginning to dislike perl and I have not written more than 100  
>> lines of it
>> in my life :)
>
> One advantage is the massive amount of modules already written to  
> reduce the
> amount of work you have to do; one disadvantage is all of the  
> massive amount
> of modules one must wade through to determine what you might  
> actually need.
> Of course using CPAN makes that easier but then that installs  
> outside of
> port, which means you can't depend on it for other ports or use
> uninstall/activate/deactivate to manage it, etc.

Also, is it still true than CPAN can get clobbered by Apple Updates?   
This is one of the best selling points of MacPorts.

> I guess what I'm trying to say is, if there's an easy answer, I  
> haven't
> heard it.


Rarely is it easy :)  Curious, without going into a lot of detail, how  
does the hugely raves about apt-get and equivalent get past all this?
--
Scott