handle only subports install files

[Ryan Schmidt]

On Mar 19, 2012, at 14:07, Joshua Root wrote:

> On 2012-3-20 06:00 , Ryan Schmidt wrote:
>> 
>> On Mar 19, 2012, at 13:39, Joshua Root wrote:
>> 
>>> On 2012-3-20 05:34 , Ryan Schmidt wrote:
>>>> 
>>>> Yes, and that's valuable... but sometimes, like in Bradley's mysql-connector-cpp, or in my VillainousStyle, there might not be a particular port that it would be appropriate to call the default.
>>> 
>>> There is no "default". There are just a bunch of ports. You get
>>> precisely the one you ask for.
>> 
>> There absolutely is a default, within the python portgroup. Same for the perl5 and soon php portgroups. If you install py-foo, MacPorts installs the default version, which might be py24-foo or py27-foo or something else depending on the port. But MacPorts also actually installs py-foo, which serves no purpose and gets in the way.
> 
> We were talking about subports in general, not what the portgroups do.

Exactly. I'm talking about a feature I believe is useful when using subports in general. And I'm pointing to the portgroups as an example, because they already partly implement the "default subport" concept. I'm pointing out the limitations and problems with the way the portgroups do it, and suggesting that by adding specific support for a "default subport" in base, we could both improve and simplify the portgroups and make it easier to write other ports using subports.


>> Not only that, but it's tedious to have to add the half dozen or so lines needed to make a stub port to each of these portgroups, not to mention individual ports that want to use this layout. 
> 
> So I guess we shouldn't do it?

I'm not sure what you mean by that, but I was trying to say that, based on the "don't repeat yourself" principle, anytime I find myself copying code blocks, it's an opportunity to think about refactoring. So I'm trying to suggest a way that we could eliminate the need to copy several lines of code in each such portfile, and also streamline the user experience, by adding a "default subport" feature.


>>> If you can't decide which one to declare
>>> at the top level, roll dice or something.
>> 
>> The py-* / p5-* / soon to be php-* ports demonstrate the utility of being able to define a port whose name is not any of the intended subports. I wouldn't want to have to name a port "py27-foo" for example; it's nice to be able to give it a version-agnostic name like "py-foo". That doesn't mean I want the user to be able to install "py-foo" itself.
> 
> The portgroup could easily change the name if desired.

Are you suggesting that the directory the portfile is in would still be called "py-foo" and that the portgroup would set name to for example py27-foo (picking one of the port's supported python versions) instead of py-foo? I can see how that might be possible with the perl5 and php portgroups since they use a .setup procedure that sets the name, but the python portgroup relies on each portfile to set the name, so I'm not sure how that would work.

"port lint" would also complain about the mismatch between the directory name and the port name, but that's a minor detail.