Stuart Henderson wrote:
> On 2026/09/28 16:09, David Uhden Collado wrote:
>> It should also make future github-cli updates easier. When the survey
>> dependency changes, the patches can be tested directly against the new
>> upstream version and refreshed or removed if they are no longer needed,
>> without having to maintain and update a separate fork first.
> 
> survey is abandoned upstream so this isn't really a consideration.
> (and if it wasn't abandoned we'd probably be able to get this fix
> committed upstream anyway..)
> 
>> +post-extract:
>> +	${UNZIP} -oq ${DISTDIR}/go_modules/${SURVEY_MOD}/@v/${SURVEY_V}.zip \
>> +	    -d ${WRKDIR}/survey-extract
>> +	mv ${WRKDIR}/survey-extract/github.com/AlecAivazis/survey/v2@${SURVEY_V} \
>> +	    ${WRKDIR}/survey
>> +	rm -rf ${WRKDIR}/survey-extract
>> +
>> +post-patch:
>> +	patch -d ${WRKDIR}/survey -p0 \
>> +	    < ${FILESDIR}/patch-survey_terminal_runereader_posix_go
>> +	patch -d ${WRKDIR}/survey -p0 \
>> +	    < ${FILESDIR}/patch-survey_go_mod
> 
> it would indeed be nice to have a proper way to patch go modules
> and, if we had that, moving from the fork to port patches would make
> sense. that would be useful for much more than just github-cli.
> but this approach with ${FILESDIR} and these custom targets isn't
> really a sustainable properly-integrated way to do this.

I agree. In this particular case, if survey is abandoned upstream, then 
the argument about making future upstream updates easier does not really 
apply.

More generally, though, I think it would be useful to improve the ports 
infrastructure for languages with their own package managers, and 
perhaps make the different modules behave a bit more consistently.

For example, the Go module can generate its .inc files without mixing 
unrelated output into the generated data. With Cargo, the equivalent 
workflow is less clean and often requires working through temporary 
files rather than writing the generated information directly where it 
belongs. Cabal is further behind in this regard, since there is no 
equivalent mechanism in the ports infrastructure at all; you currently 
need an external tool such as cabal-bundler, and parts of that workflow 
can end up using and modifying the user's home directory instead of 
keeping everything contained under places such as /usr/obj or 
/usr/distfiles.

So I agree that the custom ${FILESDIR} plus post-extract/post-patch 
approach is not a good general solution. A properly integrated mechanism 
for patching vendored Go modules would be much better, and I think there 
is also a broader opportunity to make the Go, Cargo, and Cabal module 
workflows more homogeneous where that makes sense.