mitmproxy @0.17.1 -- New port

[iamGavinJ (GΛVĪN)]

New port for ​https://mitmproxy.org/

This is a binary release built by the author and does not require the python dependencies that the py-mitmproxy port does.

[iamGavinJ (GΛVĪN)]

Fixed tab/space indentation

[mf2k (Frank Schima)]

Cc'ing the maintainers of the existing py-mitmproxy port. We cannot have duplicate ports.

[petrrr]

The reporter seems to be aware of port py-mitmproxy, it is specified as conflicting.

I am not sure what exactly the purpose of the port should be, but the description above indicates that the reporter wants to install a binary build to avoid the dependency on Python. As far as i understand this is not the approach MacPorts uses. Macport's Python packages always install against a set of Python versions provided by Macports and do not rely on system's Python of which the version is not controlled by MacPorts.

I therefore would propose to close this ticket as invalid, and only take it as hint to update the existing port. I'll wait for a final comment from the reporter and close this within some days if there is no good reason.

[mf2k (Frank Schima)]

@ petr: I completely agree with you.

[petrrr]

See #51562, which tracks update of port py-mitmproxy.

[petrrr]

You might already have noted that I upgraded py-mitmproxy. See ticket #51562 for more details.

The Portfile provided with this ticket proposes some firewall settings in the activation/deactivation phase. Is this something we want to adopt for the py-mitproxy port? Or do we prefer that users make such settings consciously/manually?

[iamGavinJ (GΛVĪN)]

Sorry for the delay replying... Happy to close this ticket. I submitted it simply because I had already written the portfile after not finding the port. I was limiting my search to the specific name (didn't think to prefix with "py-", or "*mitm*" for that matter).

Replying to petr@…:

The reporter seems to be aware of port py-mitmproxy, it is specified as conflicting.

I am not sure what exactly the purpose of the port should be, but the description above indicates that the reporter wants to install a binary build to avoid the dependency on Python. As far as i understand this is not the approach MacPorts uses. Macport's Python packages always install against a set of Python versions provided by Macports and do not rely on system's Python of which the version is not controlled by MacPorts.

I therefore would propose to close this ticket as invalid, and only take it as hint to update the existing port. I'll wait for a final comment from the reporter and close this within some days if there is no good reason.

[iamGavinJ (GΛVĪN)]

Maybe the firewall additions could be included as a variant?

Replying to petr@…:

You might already have noted that I upgraded py-mitmproxy. See ticket #51562 for more details.

The Portfile provided with this ticket proposes some firewall settings in the activation/deactivation phase. Is this something we want to adopt for the py-mitproxy port? Or do we prefer that users make such settings consciously/manually?

[petrrr]

I submitted a ​PR on Github for review of the proposed variant.

@gavin, would you be interested in maintaining this port?

[petrrr]

Closing as agreed in PR: ​https://github.com/macports/macports-ports/pull/434