Releasing code as portgroup instead of in base/

[Daniel J. Luke]

On Oct 13, 2014, at 6:19 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> On Oct 13, 2014, at 5:00 PM, Daniel J. Luke wrote:
>> On Oct 13, 2014, at 5:54 PM, Ryan Schmidt wrote:
>> 
>>>> On Oct 10, 2014, at 9:05 AM, Daniel J. Luke wrote:
>>>> 
>>>>> I disagree that we should move as many portgroups as possible into base. Moving the portgroups out of base and into the ports tree years ago has been of great benefit in encouraging the development of portgroups. No matter how agile the release process of base may become, nothing compares to being able to put a file in a directory and having it available to the entire MacPorts userbase in minutes.
>>>> 
>>>> right - and I'm saying that that's actually a problem
>>>> 
>>>> 'easy' injection of code into the tree without going through any kind of release process/review is something we should minimize.
>>> 
>>> Playing devil's advocate for a moment, are you suggesting that we institute a similar release process/review for portfile changes?
>> 
>> we should continue improving base/ (non-root execution, sandboxing, trace mode, etc) so that 'rogue' portfiles cannot do damage (or can do limited damage) so that this isn't necessary (or is less necessary).
> 
> Sure, and we're already pretty good at that, and will continue to get better. But if Portfiles cannot do damage,

they still can (currently)

> then portgroups, which are merely code included by portfiles, cannot do damage either. There's no difference in the capabilities of code in a portgroup vs code in a portfile.

portfiles are usually simpler than portgroups (almost by definition).

a portfile that looks like a few key-value pairs is a lot easier to trust/validate than something that sources a bunch of tcl from a portgroup.

> I also see a problem if a port uses a portgroup, and wants to use two different ports, at different revisions, that expect different versions of the portgroup. Is this kind of problem the reason why you're against portgroups?

this is one of the reasons why I find them somewhat problematic, yes.

Another way to look at it is that generally the portgroup is unversioned (and an end user doesn't necessarily know which version of a portgroup was used when a particular port was installed).

> I do want there to be lots of metadata about ports on the new MacPorts web site, including information such as results of buildbot builds. If we get to the point of automating test runs that could be included as well. The web site could also make that information available to the command line MacPorts program in some way if we wanted to do that.

I think that would be great.

If I were writing macports from scratch, I might have 'remote portfiles' be the default, you would ping a portfile server to see what was available, or pull whatever recipe for building a port that you selected. End users could select various criteria that they wanted enforced (only install ports that have been reviewed by a MP committer, only install ports that passed a test suite, only install ports that are GPL compliant, only instal ports that built on the buildbot...). It could be simpler for people to (attempt to) install a port at a particular version/revision too.

... but those additional capabilities are probably of marginal utility for most people, so I don't think that they're reasonable immediate design goals - instead there are clearly some areas where we can and should continue to improve.

>>> Because if so, that would be stifling, and if not, then I don't see it working very well, since it's previous been very convenient to be able to make changes in portgroups simultaneously with changes in ports. Losing that ability will make working with portgroup more difficult.
>> 
>> it's not all or nothing, but I think we should generally push more code into base/ (especially after an portgroup has matured somewhat) rather than pushing for more and more code out of base/
> 
> Even for decade-old build systems like imake that are only used by a handful of ports?

yes, for as long as we wanted to support imake builds

> That would for me be the definition of special-case code that doesn't belong in base.

most of base could be construed as special-case code ;-)

> The other thing I really like about portgroups is that all code related to a particular thing is contained within a single file. When I want to investigate a feature in base, I have to first use grep to figure out what file(s) the code is in, and it's usually spread out all over the place. In the case of imake support, it's only in two files, portconfigure.tcl and portutil.tcl, but that first file is 800 lines long and, like most of base, hard to read, for someone otherwise only accustomed to reading portfiles. Having all the imake- (or whatever-) related code in a single short portgroup file is much easier to understand and change.

it seems like that is a problem with base/ and our dev documentation (or lack of) which it would make sense to fix rather than work around it in that way.

It would probably even be possible/reasonable to keep the portgroup implementation the same, and just have base source (some?) from a base install location instead of (or in addition to) the ports tree.

--
Daniel J. Luke                                                                   
+========================================================+                        
| *---------------- dluke at geeklair.net ----------------* |                          
| *-------------- http://www.geeklair.net -------------* |                          
+========================================================+                        
|   Opinions expressed are mine and do not necessarily   |                          
|          reflect the opinions of my employer.          |                          
+========================================================+