buildout
buildout copied to clipboard
buildout
Feature request: Stop suppressing "disallowed host" message.
Before i go off and write a PR for this, i'm hoping to get some feedback to see if my use case is of any interest to other zc.buildout users.
I just spent some time debugging a buildout (zc.buildout 2.11.5) where i got "Error: Couldn't find a distribution for". After diving in, i found the code in zc.buildout.AllowHostsPackageIndex where it patches the distutils logger to suppress the "disallowed host" message (https://github.com/buildout/buildout/blob/master/src/zc/buildout/easy_install.py#L125). After disabling this monkey patch, buildout nicely told me that my allow-hosts didn't allow downloads from files.pythonhosted.org:
Note: Bypassing https://files.pythonhosted.org/packages/c6/fa/6b18113ad8beea354f13b091148c2895d7dd0b37182ab0a569a5bd0e9c27/mr.developer-0.1.zip#sha256=b098f6af5d2633a2d80effa0885fdc4e3111b6b9152d7a3b69e8b95162156ea2 (disallowed host; see http://bit.ly/1dg9ijs for details).
...
Note: Bypassing https://files.pythonhosted.org/packages/c3/6b/11b99b420f6b48dc2e9898b7dfca9bf3774507028a25b59527da2861407f/mr.developer-1.38.tar.gz#sha256=60e531f2f8214aa60eba11fb826bc45c42fb06809e801ab6080a80e866fccad9 (disallowed host; see http://bit.ly/1dg9ijs for details).
Although this output was very verbose (i truncated the output, but each available version of the package was listed separately), it would have been very helpful to me.
Is this something that should be changed? From my perspective, removing the monkey patch altogether seems better. Or could we enable the monkey patch with a command line switch, like --suppress-allow-hosts-message?
Update: This looks like a dupe of #447, so i'm closing it. But #447 still deserves a follow-up i think.
The problem is that we cannot do a follow-up on #447, at least not for those that get that problem now.
Because, even if we made a new release, the release can't be found because of the issue....
In the default setup, everything is fine. It is only if you restricted it in the buildout.cfg that it goes wrong. And we can't warn you in the past. A bit of a catch-22.
The only thing that could help is some documentation somewhere. We could mention it in the changelog, though there is no actual change. Would that be a logical place to look?
@reinout First off, nice to talk to you again :)
If i understand you correctly, you say a new zc.buildout release which addresses this issue wouldn't find its way to affected users, because of the issue itself.
Something i did frequently last year in order to keep older buildouts running with all the setuptools / pypi changes is to pip-install modern setuptools and zc.buildout in the virtualenv used by buildout. That's how we got zc.buildout 2.11.5 in this buildout (which we inherited with the existing project). In that scenario, having a zc.buildout update would help.
A changelog message would draw attention and might help, but i still think it would be more helpful if the issue were addressed in some other way as well. I'd say it would be worth the effort.
Yes, that's a very valid reason! I didn't think of that. Ok, it is good to do something about it.
It shouldn't be too invasive, though.