Apparently one of the oldest feature requests around... http://trac.macports.org/projects/macports/ticket/463 I created a basic implementation, for later expansion: http://trac.macports.org/projects/macports/ticket/12211 It does the following: - implicitly checks that Tcl syntax is reasonable - checks the document for invalid UTF-8 sequences - checks for blank newlines after certain fields - checks for trailing whitespace before newline - checks that PortSystem is present (but only once) - checks that all required variables are present - checks for maintainer darwinports@opendarwin.org Results are divided into (fatal) errors and warnings, while passed checks can be viewed using the -v flag. There are several other Portfile checks left TODO, but at least it's a start in the right direction... Note: it currently *only* checks the Portfile, and not the files directory nor the generated destroot. --anders PS. Of course it is inspired by FreeBSD portlint(1) http://www.freebsd.org/cgi/man.cgi? query=portlint&sektion=1&manpath=FreeBSD+Ports
Apparently one of the oldest feature requests around... http://trac.macports.org/projects/macports/ticket/463
I created a basic implementation, for later expansion: http://trac.macports.org/projects/macports/ticket/12211
I guess there will be NO feedback on this until it has been committed to trunk, so maybe we can do that now ? It does highlight some portstyle issues to be sorted out, like where the newlines should go and amounts of tabbing. --anders
On Jul 10, 2007, at 5:47 AM, Anders F Björklund wrote:
I created a basic implementation, for later expansion: http://trac.macports.org/projects/macports/ticket/12211 I guess there will be NO feedback on this until it has been committed to trunk, so maybe we can do that now ?
I say go for it! -- enp
On Jul 10, 2007, at 07:47, Anders F Björklund wrote:
It does highlight some portstyle issues to be sorted out, like where the newlines should go and amounts of tabbing.
Seems like coding style has thus far been left up to each port author. There has been some debate on whether to use tabs or spaces. Different people have different opinions on this, with people on both sides claiming that their way is easier for them and/or their text editors. I use tabs to control indentation at the beginnings of lines, but spaces to keep columns aligned. This seems like the best idea to me. Many portfiles currently use tabs everywhere, even to keep columns aligned, which of course fails if I'm using different tab settings than the portfile author. Other portfiles use spaces everywhere. I think the idea of portlint was supposed to be a utility that checks for valid syntax, valid variables, required variables and so on, but I don't know that it needs to enforce any particular coding style -- especially not until there is a clear consensus about what that style should be. The last time we tried to settle even the tabs-vs.-spaces issue there was a heated debate and no resolution. The style of my portfiles should be consistent with each other -- with perhaps a few exceptions for portfiles I haven't gotten to yet. But my port writing style is different from some others. Since we had no real consensus on style, I wanted to try something different to see how I liked it. So far, I kinda do.
Ryan Schmidt wrote:
It does highlight some portstyle issues to be sorted out, like where the newlines should go and amounts of tabbing.
Seems like coding style has thus far been left up to each port author.
Yup, seems like it. Or up to general rules or customs, rather than verifying it automatically against some common standard.
There has been some debate on whether to use tabs or spaces. Different people have different opinions on this, with people on both sides claiming that their way is easier for them and/or their text editors.
While at the same time making it harder for everyone reading... I think it's a poor tradeoff, better to pick One True Portstyle.
I use tabs to control indentation at the beginnings of lines, but spaces to keep columns aligned. This seems like the best idea to me. Many portfiles currently use tabs everywhere, even to keep columns aligned, which of course fails if I'm using different tab settings than the portfile author. Other portfiles use spaces everywhere.
The simple solution being defining tabs to something like 8. Or use spaces everywhere. Just as long as it is consistent ?
I think the idea of portlint was supposed to be a utility that checks for valid syntax, valid variables, required variables and so on, but I don't know that it needs to enforce any particular coding style -- especially not until there is a clear consensus about what that style should be. The last time we tried to settle even the tabs-vs.-spaces issue there was a heated debate and no resolution.
The whining about whitespace can be made into an option, I'm just not familiar enough with the MacPorts API to make it one...
The style of my portfiles should be consistent with each other -- with perhaps a few exceptions for portfiles I haven't gotten to yet. But my port writing style is different from some others. Since we had no real consensus on style, I wanted to try something different to see how I liked it. So far, I kinda do.
The main idea of making the actual tool was to see how much differences there actually is, in terms of hard port numbers ? Haven't actually gotten around to doing the "port lint all" yet, just as I haven't done "port rpm all" just yet either :-) --anders
On Jul 10, 2007, at 05:47, Anders F Björklund wrote:
Apparently one of the oldest feature requests around... http://trac.macports.org/projects/macports/ticket/463
I created a basic implementation, for later expansion: http://trac.macports.org/projects/macports/ticket/12211
I guess there will be NO feedback on this until it has been committed to trunk, so maybe we can do that now ?
My only question is this: 78 proc lint_main {args} { 79 global UI_PREFIX portname portpath 80 set portfile ${portpath}/Portfile It's inadvisable to make assumptions about the Portfile path from within a target -- should this be implemented outside of the build targets? -landonf
On Jul 10, 2007, at 16:31, Anders F Björklund wrote:
Ryan Schmidt wrote:
There has been some debate on whether to use tabs or spaces. Different people have different opinions on this, with people on both sides claiming that their way is easier for them and/or their text editors.
While at the same time making it harder for everyone reading... I think it's a poor tradeoff, better to pick One True Portstyle.
I use tabs to control indentation at the beginnings of lines, but spaces to keep columns aligned. This seems like the best idea to me. Many portfiles currently use tabs everywhere, even to keep columns aligned, which of course fails if I'm using different tab settings than the portfile author. Other portfiles use spaces everywhere.
The simple solution being defining tabs to something like 8.
To bring back some of the arguments from earlier threads: I do not wish to configure my editor to use 8-space tabs. I prefer 4-space tabs. This is why editors let you change the tab width: because it's a personal preference. Do not force your personal preferences on me. Different people prefer 4- or 8- or 2- or 3-space tab settings in their editors, and that's just fine. They should be allowed to do that. But this is the reason why using tabs to keep columns aligned is a bad idea and should not be done -- columns become unaligned for all tab-width settings other than the one the author used. This is also a reason why using spaces everywhere, even for line indentation, is bad IMHO: it forces your personal line indentation preference on everyone else.
Or use spaces everywhere. Just as long as it is consistent ?
I'd prefer not to use spaces everywhere, because I like using the tab key and other indentation functions of my editor, which uses the tab character. I do not wish to reconfigure my editor to use space characters because I use tab characters in all the other non-MacPorts text files that I edit with my editor. This is why I believe tabs at the beginning of lines and spaces within lines is the best solution. I can continue to use the tab key to indent lines, which I'm used to. I can continue to use my editor's increase-indentation and decrease-indentation functions, which also use tab characters. And for keeping columns aligned, I can use spaces, and regardless of my or your tab indentation preferences, the columns remain aligned. However, if it is decided to enforce only spaces everywhere and banish the tab character, then so be it. But then I will likely need to develop some scripts which convert portfiles to and from tabbed format, so that I can deal with them easily in my editor. Or I will have to write a script which I will then use to open portfiles, which configures the editor to use only spaces, only for that one file. Other users will of course argue that their editors are configured to use spaces, and they do not wish to reconfigure their editors to use tabs... I think this is where we stalemated last time.
Landon Fuller wrote:
I guess there will be NO feedback on this until it has been committed to trunk, so maybe we can do that now ?
My only question is this:
78 proc lint_main {args} { 79 global UI_PREFIX portname portpath 80 set portfile ${portpath}/Portfile
It's inadvisable to make assumptions about the Portfile path from within a target -- should this be implemented outside of the build targets?
An API for getting the name would be much better. I blame inexperience with Tcl and MacPorts... :-) --anders
On 10 Jul, 2007, at 18:15, Ryan Schmidt wrote:
This is also a reason why using spaces everywhere, even for line indentation, is bad IMHO: it forces your personal line indentation preference on everyone else.
Or forces everyone else's on you. For example, I like 2-wide soft tabs. But since many others seem not to, I have put my personal preferences aside and write with 4-wide for MacPorts. That's a good thing; there's more value in consistency than in getting my way.
Or use spaces everywhere. Just as long as it is consistent ?
I'd prefer not to use spaces everywhere, because I like using the tab key and other indentation functions of my editor, which uses the tab character. I do not wish to reconfigure my editor to use space characters because I use tab characters in all the other non- MacPorts text files that I edit with my editor.
That can still be problematic. I write code with the assumption that it will be edited and viewed on a 80-char-wide terminal. That means that, if I were to use 2-wide hard tabs, lots of lines could start wrapping in places they shouldn't for others' settings. Aside from that, the argument "we should use hard tabs to avoid enforcing personal indentation preferences on others" is fallacious, because many people (such as me) prefer soft tabs :) Basically, I would rather a standard width were dictated from "on high" than it be left to users. I don't care what it is (and it probably won't be what I'd like) so long as the Portfile looks the same to me as to everyone else. Chris
Ryan Schmidt wrote:
The simple solution being defining tabs to something like 8.
To bring back some of the arguments from earlier threads: I do not wish to configure my editor to use 8-space tabs. I prefer 4-space tabs. This is why editors let you change the tab width: because it's a personal preference. Do not force your personal preferences on me. Different people prefer 4- or 8- or 2- or 3-space tab settings in their editors, and that's just fine. They should be allowed to do that.
It's of course possible to keep indentation in Portfiles up to the port maintainer. Maybe I should have mention that suggested "port lint" didn't actually check any indentation, just the use of newlines between certain port constructs... BTW; 8 is the default Unix hard tab size, not anything personal (it will show up when using for instance a browser or terminal)
But this is the reason why using tabs to keep columns aligned is a bad idea and should not be done -- columns become unaligned for all tab-width settings other than the one the author used. This is also a reason why using spaces everywhere, even for line indentation, is bad IMHO: it forces your personal line indentation preference on everyone else.
Unless there is a common project line indentation standard, it's no useful idea of trying to force anything upon anyone.
Other users will of course argue that their editors are configured to use spaces, and they do not wish to reconfigure their editors to use tabs... I think this is where we stalemated last time.
Maybe just keep it flexible then ? Or leave it to the Portfile prettyprinter, to show the Portfiles in some readable manner... (and adding some syntax coloring wouldn't hurt either, probably can use Tcl with some extra keywords for the common variables?) Standardizing the variable order might not be a bad thing though, nor providing a Portfile template (whether blank or interactive). --anders
On 11.7.2007, at 2.06, Anders F Björklund wrote:
Ryan Schmidt wrote:
The simple solution being defining tabs to something like 8.
To bring back some of the arguments from earlier threads: I do not wish to configure my editor to use 8-space tabs. I prefer 4-space tabs. This is why editors let you change the tab width: because it's a personal preference. Do not force your personal preferences on me. Different people prefer 4- or 8- or 2- or 3-space tab settings in their editors, and that's just fine. They should be allowed to do that.
It's of course possible to keep indentation in Portfiles up to the port maintainer. Maybe I should have mention that suggested "port lint" didn't actually check any indentation, just the use of newlines between certain port constructs...
BTW; 8 is the default Unix hard tab size, not anything personal (it will show up when using for instance a browser or terminal)
To say my word, too, here: I have tried to follow the traditional model quite long, using lots of tabs actually. That of course works quite well, as whitespace in proper places makes the file readable. Lately I have changed my own writing somewhat, due to my use of emacs, because then I don't have to take care of the indentation myself. Emacs has its own mode for tcl, that works quite well. It can be adjusted, so if in the future a common coding style is agreed upon, perhaps a document page is written to define the correct values for all the variables concerned.
But this is the reason why using tabs to keep columns aligned is a bad idea and should not be done -- columns become unaligned for all tab-width settings other than the one the author used. This is also a reason why using spaces everywhere, even for line indentation, is bad IMHO: it forces your personal line indentation preference on everyone else.
Unless there is a common project line indentation standard, it's no useful idea of trying to force anything upon anyone.
I agree. However, I'd say, it's perhaps more important to have some indentation (I think this is the case) than to try very hard to define, what it's like.
Other users will of course argue that their editors are configured to use spaces, and they do not wish to reconfigure their editors to use tabs... I think this is where we stalemated last time.
Maybe just keep it flexible then ? Or leave it to the Portfile prettyprinter, to show the Portfiles in some readable manner... (and adding some syntax coloring wouldn't hurt either, probably can use Tcl with some extra keywords for the common variables?)
Standardizing the variable order might not be a bad thing though, nor providing a Portfile template (whether blank or interactive).
--anders
I'll second that. Some of the portfiles are large, and to read them is a lot easier, if variables, phases, and variants are always in some definite order. I don't myself see very much significance between different indentation styles. I'd guess most of files can read files with some (intelligible) indentation. Flexibility on the other hand makes it easier to write them, as each one of us likes to do things in a personal way (that said, it doesn't matter to me, if I can adjust my tcl-mode to indent the lines in the generally accepted and recommended manner). ! ! Jyrki Wahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386
On 11 Jul 2007, at 07:08, Jyrki Wahlstedt wrote:
On 11.7.2007, at 2.06, Anders F Björklund wrote:
Ryan Schmidt wrote:
The simple solution being defining tabs to something like 8.
To bring back some of the arguments from earlier threads: I do not wish to configure my editor to use 8-space tabs. I prefer 4- space tabs. This is why editors let you change the tab width: because it's a personal preference. Do not force your personal preferences on me. Different people prefer 4- or 8- or 2- or 3- space tab settings in their editors, and that's just fine. They should be allowed to do that.
It's of course possible to keep indentation in Portfiles up to the port maintainer. Maybe I should have mention that suggested "port lint" didn't actually check any indentation, just the use of newlines between certain port constructs...
BTW; 8 is the default Unix hard tab size, not anything personal (it will show up when using for instance a browser or terminal)
To say my word, too, here: I have tried to follow the traditional model quite long, using lots of tabs actually. That of course works quite well, as whitespace in proper places makes the file readable. Lately I have changed my own writing somewhat, due to my use of emacs, because then I don't have to take care of the indentation myself. Emacs has its own mode for tcl, that works quite well. It can be adjusted, so if in the future a common coding style is agreed upon, perhaps a document page is written to define the correct values for all the variables concerned.
As everyone likes to have its tabs in a different size, use her/his editor of choice, etc., etc. I say: Lets go for spaces only. Once everyone has accommodated to it, we'll all be happy.
But this is the reason why using tabs to keep columns aligned is a bad idea and should not be done -- columns become unaligned for all tab-width settings other than the one the author used. This is also a reason why using spaces everywhere, even for line indentation, is bad IMHO: it forces your personal line indentation preference on everyone else.
Unless there is a common project line indentation standard, it's no useful idea of trying to force anything upon anyone.
I agree. However, I'd say, it's perhaps more important to have some indentation (I think this is the case) than to try very hard to define, what it's like.
Other users will of course argue that their editors are configured to use spaces, and they do not wish to reconfigure their editors to use tabs... I think this is where we stalemated last time.
Maybe just keep it flexible then ? Or leave it to the Portfile prettyprinter, to show the Portfiles in some readable manner... (and adding some syntax coloring wouldn't hurt either, probably can use Tcl with some extra keywords for the common variables?)
Standardizing the variable order might not be a bad thing though, nor providing a Portfile template (whether blank or interactive).
--anders
I'll second that. Some of the portfiles are large, and to read them is a lot easier, if variables, phases, and variants are always in some definite order. I don't myself see very much significance between different indentation styles. I'd guess most of files can read files with some (intelligible) indentation. Flexibility on the other hand makes it easier to write them, as each one of us likes to do things in a personal way (that said, it doesn't matter to me, if I can adjust my tcl-mode to indent the lines in the generally accepted and recommended manner).
Having a sane stringent order is a good idea. -Markus --- Markus W. Weissmann http://www.mweissmann.de/ --- Markus W. Weissmann http://www.mweissmann.de/
Weissmann Markus wrote:
As everyone likes to have its tabs in a different size, use her/his editor of choice, etc., etc. I say: Lets go for spaces only. Once everyone has accommodated to it, we'll all be happy.
But if everyone has their own idea of the indentation level, it'll be about the same anyway. i.e. instead of the "tabify" and "untabify" commits, there will be "indent" and "unindent" ? So it seems that this part of the Portfile should remain free-for-all and not be delinted... What about the newline after long_description, should that one be required or not ? --anders
participants (7)
-
Anders F Björklund
-
Chris Pickel
-
Ernest Prabhakar
-
Jyrki Wahlstedt
-
Landon Fuller
-
Ryan Schmidt
-
Weissmann Markus