Section pages with policies for Ruby, Python, Perl? (and others?)

[C. Florian Ebeling]

On Sun, Apr 12, 2009 at 2:48 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Apr 11, 2009, at 09:12, C. Florian Ebeling wrote:
>
>> I yesterday threw together a RubySection page in the wiki. Now I
>> wanted to hear thoughts if we should add one for every group of ports
>> where we have some implicit policy of how to add ports and if you like
>> the idea at all.
>>
>> I think of them to state how ports are handled in a certain
>> special-interest section: wether to add them at all or rather use
>> package managers (like gem, eggs, pear, cpan) and point users there,
>> who the interested maintainers for a certain section are, and other
>> topics which would fit here.
>
> Whether to add ports at all: I think the answer for all ports if you want to
> be able to declare something as a dependency of another port, then you need
> it to be a port.

Yes, in that case you have no option. But if you add only those
justified by such dependencies, the selection of ruby ports (to stick with
that example) would look pretty fractioned and weird to a ruby programmer
having an casual look at what MacPorts had to offer to him. So it would
not hurt to have a place which explains the reasoning behind ruby packaging
in general in MacPorts.

>
> Who the maintainers are: I think that's adequately covered by the
> maintainers field in each Portfile.

You can say that he should just run the obvious command

  port info --maintainers category:ruby | grep maintainers | awk
'{print $2}' | sort | uniq -c

and immediately see who is who. ;)

But I thought of this list of maintainers rather like the list of people who
have an opinion and interest in the section. So someone might even
have a small number of ports under the section but is not really
interested in ruby in general beyond that. And then he or she should not
or certainly has no obligation to appear there. Think of it like a special
interest group. If think a suggestion to that effect even was once made
on macports-dev@ and might have influenced me in adding that as well.

I give you another example how this might be helpful. I don't regularly use
python but just recently came across the need because of another app
that depends on it. So I looked at the collection and at the python web site.
2.6 and 3 are current. Looking at the existing library ports I realized that
the ones I need are not there as ports for these. Question now is: should I drop
back to 2.5 and base the app portfile on that or rather add portfiles or
should I abstain from adding the app as port, because we avoid python
library ports and therefore anything that depends on them as well? The
last option is probably not really satisfying, but if installing libs is a real
mess as well, than what to do? And so on. It would help to have a section
page for python which states then that new ports should depend on version
2.x if in doubt and only add lib ports following example port y.



-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com