On Tue, Jan 26, 2021 at 07:51:30PM +0000, Stuart Henderson wrote:
> One method would be to modify setuptools to prevent picking up plugins
> automatically (similar to pytest's PYTEST_DISABLE_PLUGIN_AUTOLOAD -
> hey Kurt, did you know about that one?).
I did _not_ know about that one. Very interesting. I've made a note to
investigate it.
> I think we'd want upstream support if we did that, I imagine it will
> be a pain to maintain.
> Another option, we could do this. It's not very nice because it will
> turn on nojunk for pretty much everything Python, but it is simple.
> Thoughts?
I wish we could mark setuptools_scm itself with nojunk, but that's not
how that works. :|
I agree that modifying setuptools is probably the better angle, but I am
unlikely to be able to dig into that this week. It's the first week of
classes at RIT so I'm unlikely to have the necessary leftover thinking
power.
I guess I worry tagging all python with nojunk perhaps causing fallout
in other ports that start picking up new dependencies beause python
keeps holding off the junk phase. Might be worth trying the below in a
test bulk.
--Kurt
> Index: python.port.mk
> ===================================================================
> RCS file: /cvs/ports/lang/python/python.port.mk,v
> retrieving revision 1.124
> diff -u -p -r1.124 python.port.mk
> --- python.port.mk 29 Dec 2020 23:59:06 -0000 1.124
> +++ python.port.mk 26 Jan 2021 19:42:47 -0000
> @@ -132,6 +132,11 @@ MODPY_SETUPUTILS = Yes
> TEST_TARGET ?= test
> _MODPY_USERBASE =
> _MODPY_PRE_BUILD_STEPS += ;${MODPY_CMD} egg_info || true
> +# Setuptools opportunistically picks up plugins. If it picks one up that
> +# uses finalize_distribution_options (usually setuptools_scm), junking
> +# that plugin will cause failure at the end of build.
> +# In the absence of a targetted means of disabling this, use a big hammer:
> +DPB_PROPERTIES += nojunk
> .else
> # Try to detect the case where a port will build regardless of setuptools
> # but the final plist will be different if it's present.
>
