I have no objection to this, but I'd quite like to keep refining bricoler ahead of bsdcan, and use that as a milestone where we start being more careful about backwards compatibility, documentation, etc.. That is, my preference would be to hold off on this patch before bsdcan.

Sure, I'll wait for a proper tagged release.

Updated to 0.2.0, should be ready to go now.

Harbormaster completed remote builds in B77327: Diff 187676.Fri, Sep 25, 2:43 PM

oop, I'm sorry, I forgot about this. :(

As it happens, @0mp went ahead and added a port based on v0.2.0 just yesterday.

Ah I missed that because of the py- prefix, I do think it should have it to be in accordance with the other ports. But no problems!

siva abandoned this revision.Fri, Sep 25, 2:54 PM

In D56766#1377033, @siva wrote:

Ah I missed that because of the py- prefix, I do think it should have it to be in accordance with the other ports. But no problems!

Hmm, is that really required for standalone applications? I'd expect it for a library, but bricoler should be able to run with a variety of python versions ideally. (Eventually I would like it to run on Linux and macOS, where it's harder to dictate which python version to use.)

Hi!

I decided against the py prefix because the Python version does not really matter to bricoler. Not all ports of software using Python during runtime have the py prefix, e.g., sysutils/arc_summary.