MacPorts Installation
harens opened this issue · comments
Hi there. I recently wrote a Portfile for mos so that it could be submitted to MacPorts. It can then be installed on macOS by running the following:
sudo port install mos
I just had a few questions to ask:
- Similar to your Homebrew package, would it be possible to either disable the auto update feature or adapt it so that it works with MacPorts? Although I'm not very experienced with Go, I would love to help if I can.
- I'm more than happy to add maintainers to the port so that you can update it more quickly with each release. I myself will update it as often as I can, though let me know if you would like to be added.
I've attached my code below in case you want to have a look. Thanks for your help.
Portfile
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
PortSystem 1.0
PortGroup golang 1.0
go.setup github.com/mongoose-os/mos 2.18.0
categories devel
license Apache-2.0
set python.versions \
38
depends_lib-append port:libftdi1 \
port:libftdi0 \
port:libusb \
port:libusb-compat \
depends_build-append \
port:python${python.versions} \
port:py${python.versions}-setuptools \
port:pkgconfig \
maintainers {@harens gmail.com:harensdeveloper} \
openmaintainer
description Mongoose OS command-line tool
long_description ${description}
checksums ${distname}${extract.suffix} \
rmd160 9ad2092f04bae9e21d26999e38699c5d3ceba7e3 \
sha256 555df9fc6a629f6b79e61245cb4802544193e14528b110c13de015e2098954be \
size 673863
build.cmd make
destroot {
xinstall -m 0755 ${worksrcpath}/${name} ${destroot}${prefix}/bin/
}
hi there! thank you
i am not familiar with macports, so what does this mean in practice? do we need to submit this file somewhere?
also, we have two streams: latest and release, does that require a separate entry?
wrt special handling - sure, we can do that. use "brew" handling as an example.
ideally, we'd also have the port updated automatically by the release script - https://github.com/mongoose-os/mos/blob/master/tools/deploy_mos.py
Thanks for your reply @rojer.
Where to submit the file
Once the Portfile is complete, I would submit it to macports/macports-ports so that it will hopefully be approved.
Latest vs Release version
I noticed in your Homebrew repo that the head option is not defined in your formulae. This would allow for the latest version to be installed without a seperate formula being required.
As for MacPorts, I think a "latest" version can be created as a subport. ld64 could act as an example, and I will try working on it.
Special handling
The main commands that would need to be run are the following
sudo port selfupdate # Update Port Tree (similar to brew update)
sudo port upgrade mosAutomatic Updates
It should be similar to the homebrew process. Only the checksums and the version number need to be updated, and a PR would need to be sent.
Thanks for your help so far.
I noticed in your Homebrew repo that the head option is not defined in your formulae. This would allow for the latest version to be installed without a seperate formula being required.
iirc this was done so we still pin to a specific hash for -latest, instead of building from master.
this makes installation faster because we also provide a bottle.
that said, i added head URL to both, won't hurt.
🎉 mos has been added to MacPorts 🎉 (project page)
(Sorry about the delay in this. It was a bit more challenging than I first thought!)
In line with your homebrew formulae, I set the build id and version manually if that helps with the special handling.
{
"build_id": "2.18.0~macports",
"build_timestamp": "2020-12-17T13:26:51Z",
"build_version": "2.18.0"
}
Would it be possible for go-dockerclient to be bumped to v1.5.0 or higher? For some reason the following line leads to undefined: idtools.Identity when running the makefile tests via MacPorts (although not through go mod download). I'm presuming it's due to the docker => moby transition, although a version bump fixes the issue either way.
Line 14 in d2abac8
I'm happy to send a PR to do this, I just wasn't sure if it would break anything that I've missed. Thanks.
is it just the release or is it possible to install from master too?
I sent a PR for the release version first since I wanted to be sure everything worked before I wrote a portfile for the "latest" version. Since then, another PR has been sent for mos-devel (not mos-latest since this isn't MacPorts convention): macports/macports-ports#9456
sure, go ahead
Done #42. Let me know if anything's not right and I'll change it accordingly.
Just to finalise everything, mos can now be installed by running the following:
mos (Project Page)
sudo port install mos
mos-devel (Project Page)
sudo port install mos-devel
Looking back at #37 (comment), the special handling section still stands (although it should be sudo port upgrade mos-devel for the latest stream), but I don't know how feasible automatic updates would be anymore since there are quite a few manual changes required in regards to dependencies.
great job, @harens! wrt updating - we need to figure a way to update this when new release is pushed.
we have update_hb.py, can you think of something similar for macports?
Apologies for the delay @rojer.
Bumping the version numbers and checksums should be straightforward for mos, and I should be able to write a GitHub Action to update these and send a PR using seaport.
mos-devel might be harder, but should hopefully still be possible
The issue for both is the go dependencies, since there are some manual changes that need to be made whenever they are updated. I personally think that we should just send a PR for the checksums and version numbers 99% of the time, and I'll update it manually when there are dependency changes, although I'm interested to hear what your thoughts are.
currently release process for mos is driven by tools/deploy_mos.py, macports should integrate with that - whatever is needed to update the macports project needs to be expressed as a python script. you can use update_hb as an example.
i don't understand the difficulty with go dependencies - those are tracked and fetched as needed by go itself during the build process, what's the problem with them?
currently release process for mos is driven by
tools/deploy_mos.py, macports should integrate with that - whatever is needed to update the macports project needs to be expressed as a python script. you can use update_hb as an example.
That's fair enough. This will be quite challenging, especially since I'm not used to your codebase yet, and as a script it requires MacPorts to already be installed. Although I'm not sure whether I'll be successful or not, I'll have a go at it anyway.
i don't understand the difficulty with go dependencies - those are tracked and fetched as needed by go itself during the build process, what's the problem with them?
Downloading deps during the build process is generally discouraged in MacPorts. @amake has listed these reasons before:
- Downloading dependencies outside of MacPorts' fetch mechanism prevents MacPorts from mirroring distfiles. That's bad for a number of reasons, such as: upstream could disappear, or we send a lot of traffic their way putting a strain on their infrastructure.
- Some build-time dependency fetching schemes lack a locking mechanism, so the exact version of the dependency used can differ depending on when exactly the build was performed. This is bad for reproducibility.
See https://trac.macports.org/ticket/61192 for more info.