Multiple Improvements to portindex2json.tcl #3

arjunsalyan · 2019-03-21T16:45:39Z

Fixed an issue where the list of categories did not have doublequotes
More fields like variants, depends_lib etc. now output values as a list of string
Added "openmaintainer: Boolean" key
Improved the output of maintainers

jmroot · 2019-03-21T17:16:36Z

You need to rebase your branch. https://trac.macports.org/wiki/WorkingWithGit#upstream-fetch

arjunsalyan · 2019-03-21T17:38:10Z

You need to rebase your branch. https://trac.macports.org/wiki/WorkingWithGit#upstream-fetch

Done, thanks.

jmroot · 2019-03-21T18:41:18Z

portindex2json/portindex2json.tcl


 package require json::write

+proc format_string {string} {


It looks like this takes a list of strings, so the names of the proc and arg are misleading. Using strings rather than string would be better.

jmroot · 2019-03-21T18:42:14Z

portindex2json/portindex2json.tcl

+proc format_string {string} {
+	if {[llength $string] > 1} {
+		foreach element $string {
+			lappend new_string "\"$element\""


Why not use ::json::write::string?

::json::write string is being already used, it would give a single string as output. But we need a list of strings which would be possible only with ::json::write array and it takes a list as an argument.

portindex2json/portindex2json.tcl

jmroot · 2019-03-21T18:46:00Z

portindex2json/portindex2json.tcl

+			lappend new_string "\"$element\""
+		}
+	} else {
+		set new_string [list "\"$string\""]


In what situation does the above foreach loop not work on a list of length 1?

I was getting error in case of "depends_lib" and "depends_build". But now I realise it was because in several cases the values of "depends_lib" and "depends_build" are empty. There sure is a better way to go through this. What do you suggest?

mojca · 2019-03-22T00:49:06Z

As a first step don't worry about commits and just try to get the contents right. Commits can be rewritten at the end.

arjunsalyan · 2019-03-22T11:45:55Z

Initially the script was using spaces and I had made use of tab with four spaces. But the indentation is itself getting converted to 8 spaces as soon as I commit the changes (although it is 4 spaces in my text editor.)

In second commit I converted all spaces to tab, and set to use 4 spaces. After the commit, irregular spacing is gone but the indentation again got converted to 8 spaces.

mojca · 2019-03-22T18:13:54Z

portindex2json/portindex2json.tcl

+	foreach key [array names portinfo] {
+		if { $key == "categories"  || $key=="variants" || $key=="depends_lib" || $key=="depends_build" } {
+			set json_portinfo($key) [::json::write array {*}[format_strings $portinfo($key)]]
+		} elseif { $key == "maintainers"} {


I would probably try to put the elseif into a function that parses and writes maintainers, so that the main function stays easy enough to comprehend.

Yes, that would be a really good improvement, thanks.

I have changed it to use a procedure. Thanks

mojca · 2019-03-22T18:18:46Z

I need to go to bed, so I didn't investigate yet, but the script throws an error for me when I try to run it:

can't read "string": no such variable
    while executing
"list "\"$string\"""
    (procedure "format_strings" line 7)
    invoked from within
"format_strings $portinfo($key)"
    ("foreach" body line 3)
    invoked from within
"foreach key [array names portinfo] {
		if { $key == "categories"  || $key=="variants" || $key=="depends_lib" || $key=="depends_build" } {
			set json_..."
    ("while" body line 10)
    invoked from within
"while {[gets $fd line] >= 0} {
	if {[llength $line] != 2} {
		continue
	}
	set len [lindex $line 1]
	set line [read $fd $len]
	array unset portinfo
	a..."
    (file "portindex2json.tcl" line 54)

arjunsalyan · 2019-03-23T07:17:30Z

I have fixed the bug.
Converted all tabs to spaces
Used the procedure for parsing maintainers, as @mojca suggested.
Used 'closedmaintainer' instead of 'openmaintainer'. It is False if "nomaintainer" or "openmaintainer" is found in the value of maintainers, else True.

The Script is working fine for me. Sample Output:

{
    "variants" : ["universal"],
    "depends_build" : ["port:pkgconfig"],
    "portdir" : "audio\/faust",
    "description" : "functional programming language for realtime audio",
    "conflicts" : "faust-devel",
    "homepage" : "http:\/\/faust.grame.fr\/",
    "epoch" : "0",
    "platforms" : "darwin",
    "name" : "faust",
    "depends_lib" : ["port:clang-6.0","port:libmicrohttpd","port:libsndfile","port:llvm-6.0","path:lib/libssl.dylib:openssl"],
    "closedmaintainer" : True,
    "license" : "GPL-2",
    "long_description" : "Faust is a functional programming language specifically designed for realtime audio applications and plugins.",
    "maintainers" : [{
        "email" : {"domain":"macports.org","name":"ryandesign"},
        "github" : "ryandesign"
    },{
        "email" : {"domain":"gmail.com","name":"aggraef"},
        "github" : "agraef"
    }],
    "categories" : ["audio","lang"],
    "version" : "2.5.23",
    "revision" : "0"
}

mojca · 2019-03-30T12:48:25Z

portindex2json/portindex2json.tcl

 package require json::write

+proc format_strings {strings} {
+    if {[llength $strings] > 1} {


As @jmroot already said, there is no reason to use the if clause here. The only problem you get is that in case the list is empty, new_strings would be left undefined. You can avoid that by first defining an empty list:

set new_strings {}

and then running the loop, without any need to check for the length.

Thanks, applied the changes and it is working fine.

mojca · 2019-03-30T12:51:44Z

portindex2json/portindex2json.tcl

+proc format_strings {strings} {
+    if {[llength $strings] > 1} {
+        foreach element $strings {
+            lappend new_strings "\"$element\""


I believe it makes sense to use [::json::write string $element] here?

Yes, it can be used with lappend.

Yes, that was what my previous comment on this line was getting at.

Yes, that was what my previous comment on this line was getting at.

Sorry, I had misinterpreted it that time.

mojca

I'm sorry that it took me so long for a proper review, I probably needed a Saturday to get slightly more free time as my Tcl skills are not something to brag about either.

There's something wrong with quoting of macfile-gimp.

Another problem is that at some point (after the first maintainer is found) the alignment of the file changes, probably because the defaults are set to a different value when you tried to fit the maintainer's info into a single line.

mojca · 2019-03-30T12:53:52Z

portindex2json/portindex2json.tcl

-            set json_portinfo($key) [::json::write array {*}$portinfo($key)]
+        if { $key == "categories"  || $key=="variants" || $key=="depends_lib" || $key=="depends_build" || $key=="depends_fetch" } {
+            set json_portinfo($key) [::json::write array {*}[format_strings $portinfo($key)]]
+        } elseif { $key == "maintainers"} {


We should use consistent whitespacing inside braces.

I don't know why this highlighter is marking this one red, but according to most other sources it seems that we don't use a space after { and before }.

I have made it consistent (without the use of spaces)

The red highlighting is still there.

I have absolutely no idea why the strange highlighting here, but I assume we can ignore it. But there are other locations where there's still whitespace. Sorry for nitpicking.

No that is perfectly fine. We need the final code in perfect shape, and I am ready for any number of changes. I will give it a more detailed check. Thanks

mojca · 2019-03-30T12:57:03Z

portindex2json/portindex2json.tcl

+}
+
+proc remove_extra_braces {text} {
+    return [regsub -all {[\{\}]} $text ""]


This seems to do the job, but I'm not a huge fan of this approach which blindly replaces all braces. I hope that @jmroot or @MarcusCalhoun-Lopez are slightly more skilled in Tcl and could help with some nice command to properly "unquote" text without "hard-code" replacements?

As an explanation for anyone not following why this was needed: Whenever the Portfile uses

long_description ${description}

the long description ended up with an additional pair of undesired braces.

We should probably just stop fixing that after the fact. The right thing to do in the Portfile is write long_description {*}${description}.

That said, if $long_description is length 1 then it's safe to use [lindex $long_description 0].

Now that I saw the source of the problem, I agree that fixing it here is kind of the wrong place to perform any fixes.

However, we would need to fix nearly 4000 portfiles if we follow your suggestion. Definitely off-topic for this PR, but my naive question is: Tcl is eventually able to print the string to the screen without all the wrong quoting. Is there really no way to write the properly expanded string to PortIndex automatically if we add some fixes to the base?

Tcl is eventually able to print the string to the screen without all the wrong quoting.

It's not "wrong" quoting, it's precisely the quoting needed to define the list as it was given. If you want to join all the list elements together into one string, you use join. Tcl doesn't just decide to do this on its own; have a look at what action_info does.

Is there really no way to write the properly expanded string to PortIndex automatically if we add some fixes to the base?

It would be very strange to have the value of $long_description in the Portfile be different to the value you get from reading the PortIndex. Think about what this would mean: you would get one answer from mportinfo and another from mportlookup (both return the same PortInfo array, but the former does it by parsing the Portfile and the latter gets it from the PortIndex.)

mojca · 2019-03-30T13:07:03Z

portindex2json/portindex2json.tcl

-        if { $key == "categories"} {
-            set json_portinfo($key) [::json::write array {*}$portinfo($key)]
+        if { $key == "categories"  || $key=="variants" || $key=="depends_lib" || $key=="depends_build" || $key=="depends_fetch" } {
+            set json_portinfo($key) [::json::write array {*}[format_strings $portinfo($key)]]


This is a bit of personal opinion, but I would rewrite this in such a way that ::json::write array would already be called inside the format_strings function. Then you would only call something like

set json_portinfo($key) [strings2json_array $portinfo($key)]

(I changed the function name from format_strings to strings2json_array. Not sure if that's the best name either.)

mojca · 2019-03-30T13:28:13Z

portindex2json/portindex2json.tcl

    foreach key [array names portinfo] {
-        if { $key == "categories"} {
-            set json_portinfo($key) [::json::write array {*}$portinfo($key)]
+        if { $key == "categories"  || $key=="variants" || $key=="depends_lib" || $key=="depends_build" || $key=="depends_fetch" } {


You are using inconsistent whitespacing here. My preference and generally the style used elsewhere is to use whitespace around ==.

Another way of writing this would be to check whether $key is in a list of strings:

if {[lsearch -exact {categories variants depends_lib dependes_build dependes_fetch} ${key}] != -1} {

even though I'm not sure if that makes the comparison any clearer (in python it would have been nicer, but here the syntax is somewhat strange). You can probably leave it as it is, just fix the spaces.

Well, the "simplification" and maybe better said "generalisation" could have been if you compared $key to depends_*. There is also depends_test and I almost definitely forgot one of the depend types. So: check if $key equals categories or variants or depends_*.

(I would prefer if one of the more experienced developers commented about that.)

Perfect compromise.

mojca · 2019-03-30T13:35:15Z

portindex2json/portindex2json.tcl

+    return [regsub -all {[\{\}]} $text ""]
+}
+
+


Probably no need for two newlines.

portindex2json/portindex2json.tcl

arjunsalyan · 2019-03-30T19:34:44Z

There's something wrong with quoting of macfile-gimp.

In the PortIndex, the description is: description {{"Show} in Finder\" Gimp plugin} , and hence the unexpected output. What is the best thing we can do about it?

mojca · 2019-03-30T19:49:14Z

There's something wrong with quoting of macfile-gimp.

In the PortIndex, the description is: description {{"Show} in Finder\" Gimp plugin} , and hence the unexpected output.

The portfile contains \"Show in Finder\" Gimp plugin. If this gets converted into description {{"Show} in Finder\" Gimp plugin}, I would say this is a bug in macports base or portindex, maybe we can ignore it for now if already the source is buggy. And now that I see it, I would also say that the additional braces in long_description should be fixed elsewhere. @jmroot?

jmroot · 2019-03-31T01:17:30Z

You do need to join $description to get a normal string, because it is a list, which means characters that have a special meaning to Tcl are quoted.

mojca · 2019-03-31T07:36:53Z

portindex2json/portindex2json.tcl

+    foreach maintainer $maintainers {
+        if {$maintainer == "openmaintainer"} {
+            continue
+        } elseif {$maintainer == "nomaintainer"} {


Why not use "if $maintainer is not openmaintainer and is not nomaintainer, then append to the list"? And remove continue altogether.

That will be very neat. Thank You

mojca · 2019-03-31T07:38:29Z

portindex2json/portindex2json.tcl

+        unset maintainer_subobjects
+        return $maintainers_list
+    } else {
+        return "\[\]"


Switch to the same logic as in format_strings and initialize with an empty list first, then add maintainers. You can then get rid of the $ismaintainer variable altogether, and you won't need the else part either.

This whole function can probably be rewritten in five lines at most (not counting the function signature and lines containing just the closing brace): initialize an empty list, loop through maintainers, make sure it's a valid maintainer line, add maintainer to the list, return the json array with maintainers.

mojca · 2019-03-31T07:59:07Z

portindex2json/portindex2json.tcl

+    set closedmaintainer true
+    foreach maintainer $maintainers {
+        if {$maintainer == "openmaintainer" || $maintainer == "nomaintainer"} {
+            set closedmaintainer false


If you have one million maintainers and the first one is openmaintainer, you would keep iterating through all of them, just to return false at the end anyway. Don't set the variable, just return false here.

(I would somewhat prefer if the two functions (is_closedmaintainer and parse_maintainers) would be combined into one to avoid doing the same work twice, but it's true that it's then a tiny bit more convoluted code if one needs to return two results, fetch the first one, then the second one etc.)

If you have one million maintainers and the first one is openmaintainer, you would keep iterating through all of them, just to return false at the end anyway. Don't set the variable, just return false here.

Thanks

(I would somewhat prefer if the two functions (is_closedmaintainer and parse_maintainers) would be combined into one to avoid doing the same work twice, but it's true that it's then a tiny bit more convoluted code if one needs to return two results, fetch the first one, then the second one etc.)

We have to set values for two keys, so I could think of this approach only.

mojca · 2019-03-31T07:59:40Z

portindex2json/portindex2json.tcl

+            set closedmaintainer false
+        }
+    }
+    return $closedmaintainer


If you have returned earlier for all the cases where this was false, you can safely return true here.

mojca · 2019-03-31T08:00:22Z

portindex2json/portindex2json.tcl

+    foreach element $strings {
+        lappend new_strings [::json::write string $element]
+    }
+    return $new_strings


Just return the json array directly as suggested earlier.

mojca · 2019-03-31T08:06:18Z

portindex2json/portindex2json.tcl

+        set name [string trimright [lindex $email_list 1]]
+        set email(name) "\"$name\""
+        set email(domain) "\"[lindex $email_list 0]\""
+        ::json::write indented false


These intermediate identations mess up the global intentation of the file and make the spacing inconsistent in general. I'm kind of inclined to remove them altogether.

What we could (and probably should) do is provide a global option to switch between the readable and the compact form of the output. Any software would probably want the compact form for everything, not just emails. And any human being who wants to read the long form would not mind having the person split into 6 lines.

I have removed the part that was writing maintainers object into one line.

For the global part we just need to add ::json::write intended false.

mojca · 2019-03-31T08:08:02Z

portindex2json/portindex2json.tcl

+    if {[string first : [lindex $detail_list 0]] != -1} {
+        set email_list [split [lindex $detail_list 0] :]
+        set name [string trimright [lindex $email_list 1]]
+        set email(name) "\"$name\""


Why not using json function to quote the name? Here and at a few other places.

mojca · 2019-03-31T08:13:12Z

portindex2json/portindex2json.tcl

+        ::json::write indented true
+    }
+
+    set maintainer_array(github) "\"[lindex $detail_list 1]\""


I would be kind of inclined to either leave this out completely or maybe set it to null if the github handle doesn't exist. That said, we should probably get a warning whenever a github handle is missing (probably in application rather than here), so in a way making it explicit that it doesn't exist (either with an empty string or with null) is still informative if one wants to search through the json file itself. Second opinion welcome.

And please use json function for quoting.

I have set it use null if the GitHub handle is not provided.

arjunsalyan · 2019-03-31T14:04:33Z

Thanks for helping in making the code really neat and efficient @mojca. I have made another commit. Please let me know what further improvements can be done.

And what should we finally do with 'removing extra braces' from long_description ?

mojca · 2019-04-02T09:39:04Z

@jmroot: What do you think? It looks mostly ok to me by now (I didn't test the results yet).

Regarding the quoting, I'm indifferent whether we make an ugly workaround or not if the problem needs to be fixed elsewhere anyway. If we don't work around it here, it will at least serve as a reminder for fixing this properly at the source.

mojca · 2019-04-02T09:37:53Z

portindex2json/portindex2json.tcl

+        set name [string trimright [lindex $detail_list 0]]
+        set email(name) [::json::write string $name]
+        set email(domain) [::json::write string "macports.org"]
+        set email_subobject [::json::write object {*}[array get email]]


email(name) and email_subobject seem to be the same, so they could probably go out of the if-else loop?

I still want to test this (it would probably be nice to have some unit tests) to make sure that different scenarios work ok (if there is no email, if there is no github handle, if github comes before email, if it comes after email etc.)

email(name) and email_subobject seem to be the same, so they could probably go out of the if-else loop?

They are not same, email(name) is used to set the key name. And using different keys, the object email_subobject is compiled.
Am I understanding your message correctly?

I still want to test this (it would probably be nice to have some unit tests) to make sure that different scenarios work ok (if there is no email, if there is no github handle, if github comes before email, if it comes after email etc.)

I am afraid if won't work if the formats {domain:name @github} or {name @github} are altered. Because it totally relies on splitting the string at @.

What I meant was the following:

if {[string first : [lindex $detail_list 0]] != -1} { set email_list [split [lindex $detail_list 0] :] set name [string trimright [lindex $email_list 1]] - set email(name) [::json::write string $name] set email(domain) [::json::write string [lindex $email_list 0]] - set email_subobject [::json::write object {*}[array get email]] } else { set name [string trimright [lindex $detail_list 0]] - set email(name) [::json::write string $name] set email(domain) [::json::write string "macports.org"] - set email_subobject [::json::write object {*}[array get email]] -} +set email(name) [::json::write string $name] +set email_subobject [::json::write object {*}[array get email]]

I didn't test so maybe some variables need to be defined outside of the loop in order not to loose the scope.

My question is: does the code still work if you change {domain:name @github} into {@github domain:name}?

What I meant was the following:

if {[string first : [lindex $detail_list 0]] != -1} { set email_list [split [lindex $detail_list 0] :] set name [string trimright [lindex $email_list 1]] - set email(name) [::json::write string $name] set email(domain) [::json::write string [lindex $email_list 0]] - set email_subobject [::json::write object {*}[array get email]] } else { set name [string trimright [lindex $detail_list 0]] - set email(name) [::json::write string $name] set email(domain) [::json::write string "macports.org"] - set email_subobject [::json::write object {*}[array get email]] -} +set email(name) [::json::write string $name] +set email_subobject [::json::write object {*}[array get email]]

Got it, thanks! It seems that it can be done. I will give it a try.

My question is: does the code still work if you change {domain:name @github} into {@github domain:name}?

No, it won't. After splitting, it relies on github username being at index 1 and email at index 0.

My question is: does the code still work if you change {domain:name @github} into {@github domain:name}?

No, it won't. After splitting, it relies on github username being at index 1 and email at index 0.

This doesn't sound OK then. I'm not aware of any rule that dictates the github handle to come after the email address. You should iterate through entries in the list and detect github handles based on whether the first character is @, and for entries without @ distinguish emails from macports usernames based on the existence of the colon. Putting email after github handle is a perfectly valid setup; it's also valid (though discouraged) to use just email or just github handle.

Thank You for the information @mojca. I thought it was always going to be in the same format. I shall do the changes shortly.

How about this: split at space and assign GitHub username if @ is present in the entry. The other entry would then automatically be email, following the presence of : to determine the domain. And keeping in mind that entries might be missing.

Do you need an explicit splitting at space?
Just treat entries inside maintainers the same way as variants, depends_x etc. and loop over them. Then yes, you do an if-else to check for presence of '@' and ':'.

arjunsalyan · 2019-04-02T14:15:06Z

Here are some tests I ran:

maintainers {{ryandesign @ryandesign} {@agraef gmail.com:aggraef}} [ORDER CHANGED]

"maintainers"      : [{
        "email"  : {
            "domain" : "macports.org",
            "name"   : "ryandesign"
        },
        "github" : "ryandesign"
    },{
        "email"  : {
            "domain" : "gmail.com",
            "name"   : "aggraef"
        },
        "github" : "agraef"
    }]

{{ryandesign @ryandesign} {gmail.com:aggraef}} [NO GITHUB]

"maintainers"      : [{
        "email"  : {
            "domain" : "macports.org",
            "name"   : "ryandesign"
        },
        "github" : "ryandesign"
    },{
        "email" : {
            "domain" : "gmail.com",
            "name"   : "aggraef"
        }
    }]

maintainers {{ryandesign @ryandesign} {@aggraef}} [NO EMAIL]

"maintainers"      : [{
        "email"  : {
            "domain" : "macports.org",
            "name"   : "ryandesign"
        },
        "github" : "ryandesign"
    },{
        "github" : "aggraef"
    }],

I am now dropping the keys which are not available.

mojca · 2019-04-02T14:19:06Z

maintainers {{ryandesign @ryandesign} {@aggraef}} [NO EMAIL]

This would usually read

maintainers {{ryandesign @ryandesign} @aggraef}

but it need to work in both cases.

I am now dropping the keys which are not available.

That's OK.

arjunsalyan · 2019-04-02T14:22:37Z

maintainers {{ryandesign @ryandesign} {@aggraef}} [NO EMAIL]

This would usually read
maintainers {{ryandesign @ryandesign} @aggraef}
but it need to work in both cases.

I ran this : maintainers {{ryandesign @ryandesign} @aggraef}

"maintainers"      : [{
        "email"  : {
            "domain" : "macports.org",
            "name"   : "ryandesign"
        },
        "github" : "ryandesign"
    },{
        "github" : "aggraef"
    }]

and this : maintainers {{ryandesign @ryandesign} gmail.com:aggraef}

"maintainers"      : [{
        "email"  : {
            "domain" : "macports.org",
            "name"   : "ryandesign"
        },
        "github" : "ryandesign"
    },{
        "email" : {
            "domain" : "gmail.com",
            "name"   : "aggraef"
        }
    }]

This would work in both cases.

mojca

From my point of view this is now complete. The only remaining question is about keeping or dropping remove_extra_braces (leaning towards dropping for now, but no strong opinion) and the final squash of these commits.

I would be grateful for approval from another member, but if nobody complains, I'll eventually merge.

raimue · 2019-04-03T15:50:30Z

Have we verified that the changes will still work with our submission to https://repology.org, which is the main user of the PortIndex in JSON format?

raimue · 2019-04-03T15:56:29Z

Sorry, you can mostly ignore my previous comment. I should have checked before. In fact, repology maintains a separate copy of the script.

jmroot · 2019-04-03T16:03:01Z

Have we verified that the changes will still work with our submission to https://repology.org

It won't work without changes to their python code. They have expressed a desire not to maintain that script in their repo BTW.

arjunsalyan · 2019-04-03T17:14:42Z

It won't work without changes to their python code.

Yes, it won't work. But I just saw the parser being used for Macports, they are manipulating the values of only two keys: categories and maintainers. And all the work they were doing is now being done by portindex2json.tcl. Very minor changes to their code will make the new script support them.

mojca · 2019-04-03T18:23:26Z

I would currently not worry about incompatibility with repology. It uses an independent source code, so their system won't break, and the maintainer will be much happier anyway if we simply add a few lines to our buildbot configuration to generate the json file immediately after PortIndex, and also mirror that one. The fixes on the repology side should be minimal.

I would suggest squashing the commits, ask again for opinion about the ugly workaround with braces, and then merge it, unless you have some further suggestions for code improvements.

arjunsalyan · 2019-04-03T19:51:26Z

I have squashed them all into a single commit. Is that fine?

mojca · 2019-04-03T21:01:23Z

Yes.

The only super minor thing is that first line of the commit messages should be somewhat shorter (github will already not show the full commit message; it cuts at 70 characters; https://chris.beams.io/posts/git-commit/ suggests to limit yourself to 50). You can write more in the third row and further; the second row should be empty).

(In this case you could mention closedmaintainer in the third row.)

Add another key 'closedmaintainer' and keep details of maintainers in the 'maintainers' key. Output 'depends_*' and 'variants' as a list of strings.

arjunsalyan · 2019-04-04T10:27:14Z

Thank you @mojca
Following the link you had sent I have limited the characters in the first line and mentioned more details in the body.

mojca · 2019-04-05T20:35:41Z

Thank you very much for the contribution. I suggest we clean up the long descriptions later. I searched for any remaining braces and there are some in licence fields:

"license"          : "{BSD LGPL GPL}"

but that's a different issue. We should switch to SPDX one day.

jmroot reviewed Mar 21, 2019

View reviewed changes

mojca reviewed Mar 22, 2019

View reviewed changes

mojca reviewed Mar 30, 2019

View reviewed changes

mojca reviewed Mar 31, 2019

View reviewed changes

mojca reviewed Apr 2, 2019

View reviewed changes

Improve output for maintainers, depends_* and variants

3138034

Add another key 'closedmaintainer' and keep details of maintainers in the 'maintainers' key. Output 'depends_*' and 'variants' as a list of strings.

mojca merged commit cef63c3 into macports:master Apr 5, 2019

arjunsalyan deleted the feature/improvements branch April 6, 2019 09:59

Uh oh!

Multiple Improvements to portindex2json.tcl #3

Multiple Improvements to portindex2json.tcl #3

Uh oh!

Conversation

arjunsalyan commented Mar 21, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jmroot commented Mar 21, 2019

Uh oh!

arjunsalyan commented Mar 21, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mojca commented Mar 22, 2019

Uh oh!

arjunsalyan commented Mar 22, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mojca commented Mar 22, 2019

Uh oh!

arjunsalyan commented Mar 23, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mojca Mar 30, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mojca left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

arjunsalyan commented Mar 21, 2019 •

edited

Loading

arjunsalyan commented Mar 23, 2019 •

edited

Loading

mojca Mar 30, 2019 •

edited

Loading

arjunsalyan commented Mar 30, 2019 •

edited

Loading