I always used the rabbitmq management plugin to inspect messages, but I don't know if that's provided by the docker container
2017-02-01 03241, 2017
Gentlecat
we are using rabbitmq:3.6.5-management
2017-02-01 03219, 2017
Mineo
oh, great - if you access the web interface it provides, you should be able to click your way to all the messages in a specific queue
2017-02-01 03237, 2017
Gentlecat
bitmap: ^ do we have a way to do that
2017-02-01 03233, 2017
bitmap
if the port is exposed you should be able to use an ssh tunnel
2017-02-01 03203, 2017
Mineo
alternatively, the caa-indexer also has a retry and failed queue, you should be able to use the same commands you use for inspecting those to look at the messages
zas Mineo bitmap, a proposal for picard plugins, can we include a compatibility list for all plugins?
2017-02-01 03224, 2017
samj1912
so that only plugins that are tested by plugin authors to run in a particular os are included
2017-02-01 03250, 2017
samj1912
I am willing to make a PR for all the existing plugins and include the code in plugins.py to process this
2017-02-01 03220, 2017
Freso
+1 from me, but I'd say it's too late for 1.4.
2017-02-01 03231, 2017
samj1912
Freso: I think we can make it
2017-02-01 03235, 2017
samj1912
not much changes
2017-02-01 03245, 2017
samj1912
I have a windows, linux and osx machine
2017-02-01 03257, 2017
samj1912
I can test the plugins on all 3 and make a compatibilty list
2017-02-01 03216, 2017
samj1912
the code wont be large enough to cause errors, just an if while loading
2017-02-01 03237, 2017
Mineo
please don't put any more things into 1.4. a lot of the pull requests this last month have been fixes for obviously easy things from the last 2 months already
2017-02-01 03249, 2017
Freso
^
2017-02-01 03210, 2017
Freso
There are plenty of things that individually "wont be large enough to cause errors".
2017-02-01 03222, 2017
Freso
1.4 is in feature freeze. This would be a feature.
2017-02-01 03248, 2017
samj1912
hmmm, what should we do about the inclusion of non compatible windows plugins then?
2017-02-01 03252, 2017
samj1912
leave it for 1.4.1?
2017-02-01 03201, 2017
Freso
samj1912: I'd say so, yes.
2017-02-01 03241, 2017
samj1912
they cause import errors in the log which makes people wary that something is wrong with picard
2017-02-01 03252, 2017
Freso
Sure.
2017-02-01 03206, 2017
Mineo
I can't find the reason right now, why were plugins put back into the windows installer?
2017-02-01 03226, 2017
Freso
Mineo: Backwards compatibility I think.
2017-02-01 03228, 2017
samj1912
so that the required imports can be included by py2exe
2017-02-01 03234, 2017
Freso
Ah. Right.
2017-02-01 03211, 2017
Freso
Could that be written so py2exe includes the required imports, but doesn't actually bundle all the plugins?
2017-02-01 03245, 2017
samj1912
we can, well either have to write a script of some sort to figure out all the includes and add them to py2exe includes
2017-02-01 03249, 2017
Freso
(Also, it still won't help if a plugin changes dependencies between releases.)
2017-02-01 03210, 2017
samj1912
or if there is a built in functionality like that for py2exe that I am not aware of, then I am not sure
2017-02-01 03210, 2017
Freso
(Or if a new plugin is added with new dependencies.)
2017-02-01 03236, 2017
Freso
(So maybe another approach entirely should be sought.)
2017-02-01 03252, 2017
samj1912
Freso: yeah, that is why we need a more permanent solution so that picard doesn't load any plugins not marked tested for that OS
2017-02-01 03224, 2017
samj1912
the plugin author can include a COMPATIBLE_OS list in which the plugins run and are tested and picard loads only those
2017-02-01 03230, 2017
Freso
I was thinking more like making bundled and unbundled packages.
2017-02-01 03203, 2017
Freso
So the script that currently creates the plugin .zip's would include script dependencies.
2017-02-01 03216, 2017
samj1912
hmmmm
2017-02-01 03245, 2017
Freso
Because your COMPATIBLE_OS list still won't solve plugin dependency changes between versions.
2017-02-01 03200, 2017
samj1912
how so?
2017-02-01 03220, 2017
samj1912
when a plugin author updates his plugins he can simply update the COMPATIBLE_OS list
2017-02-01 03235, 2017
Freso
I may have tested a given plugin in a virtualenv on both Mac and Windows and concluded that it worked fine.
2017-02-01 03246, 2017
ferbncode has quit
2017-02-01 03256, 2017
Freso
But that doesn't mean that the additional PyPi packages in the virtualenv now exist on all Picard installations.
2017-02-01 03245, 2017
samj1912
hmm, we have to figure out some way to deal with pip packages and plugins
2017-02-01 03232, 2017
Freso
Anyway. This whole thing is too involved to make it into 1.4 in any shape or form.
2017-02-01 03239, 2017
samj1912
yeah I suppose
2017-02-01 03250, 2017
samj1912
but we need to provide some sort of fix for the errors?
2017-02-01 03257, 2017
Freso
Don't even bother. Direct your energy towards maybe getting it into 1.4.1 or 1.4.2 or just keep it for 2.0.
2017-02-01 03217, 2017
Freso
Naw. Just get it out there. Make a fix to some degree for 1.4.1.
2017-02-01 03222, 2017
samj1912
hmmm
2017-02-01 03241, 2017
ZarkBit has quit
2017-02-01 03212, 2017
Mineo
do we know if there are any plugins that are compatible with windows and which have a dependency only added via py2exe?
2017-02-01 03250, 2017
samj1912
videotools I suppose, however even that is broken
2017-02-01 03203, 2017
samj1912
We can remove sockets from the excludes and it should work though
2017-02-01 03206, 2017
Mineo
wait, why would videotools need the socket module?
We can only give hints about compatible envs and requirements, but we have no way to ensure a certain plugin will work or not, because we only have control over Picard, not plugin code nor the env Picard runs in. So the best we can do is to use safeguards (exception handling) and alert the user (error messages).
2017-02-01 03212, 2017
zas
Do any plugin break Picard ? Or they just don't load/work ?
2017-02-01 03220, 2017
samj1912
they just dont load
2017-02-01 03228, 2017
samj1912
and throw an error in the debug log
2017-02-01 03248, 2017
samj1912
which makes people think something is wrong with picard
2017-02-01 03211, 2017
samj1912
also the way picard handles erroneous plugins is not at all correct
2017-02-01 03211, 2017
zas
Well, something is wrong with Picard ;)
2017-02-01 03229, 2017
samj1912
it just gives a dialog box saying the plugin will be updated
2017-02-01 03235, 2017
mayhem does a slow clap for zas
2017-02-01 03237, 2017
samj1912
in case there are plugin errors on load
2017-02-01 03259, 2017
Mineo
ok, musixmatch is another plugin that depends on urllib and therefore on socket
2017-02-01 03205, 2017
github joined the channel
2017-02-01 03205, 2017
github
[picard] samj1912 opened pull request #610: Remove sockets from py2exe exclude list (master...patch-9) https://git.io/vDYai
2017-02-01 03205, 2017
github has left the channel
2017-02-01 03224, 2017
zas
If a dialog appears, and it is unrelated, then it is a bug. But in which exact conditions does it happen ? Is there an easy way to reproduce on linux ?
2017-02-01 03243, 2017
samj1912
zas, trying now
2017-02-01 03249, 2017
Mineo
but here's the thing: if there's not a single plugin that works by being included in the installer, I don't see any reason to include plugins in the installer at all
2017-02-01 03203, 2017
zas
The plugin UI lacks of testing imho ;)
2017-02-01 03207, 2017
Mineo
the only thing we seem to be gaining are errors in the logs right after installing picard
2017-02-01 03212, 2017
samj1912
Mineo: true
2017-02-01 03242, 2017
samj1912
if this continues, we can just remove the bundling code from setup.py and win packaging script making it like how it was before
2017-02-01 03250, 2017
zas
We can improve messages in log if they are confusing
2017-02-01 03219, 2017
Freso +1's not bundling plugins
2017-02-01 03223, 2017
samj1912
zas, can you merge that PR? I want to test if any of the currently unsupported plugins work after including sockets
2017-02-01 03212, 2017
samj1912
if not we will remove the bundling code
2017-02-01 03247, 2017
github joined the channel
2017-02-01 03247, 2017
github
[picard] zas closed pull request #610: Remove sockets from py2exe exclude list (master...patch-9) https://git.io/vDYai
2017-02-01 03247, 2017
github has left the channel
2017-02-01 03210, 2017
zas
Anyone knows why we don't have tests anymore on Picard PRs ??
2017-02-01 03210, 2017
samj1912
also I think picard testing has been disabled in travis CI?
2017-02-01 03217, 2017
samj1912
yeah ^^
2017-02-01 03234, 2017
zas
Who changed what .... that is the question...
2017-02-01 03218, 2017
samj1912
changing metabrainz's travis config seems to be the likely cause
