#metabrainz

/

      • Sophist_UK
        sam1912: Then you need to handle (in WIndows at least) getting admin priviledges.
      • 2017-05-09 12952, 2017

      • Freso
        Sophist_UK: If a user installs v2 and they have plugins in a system-wide directory, then hopefully they're the admin and can update the system-wide plugins.
      • 2017-05-09 12915, 2017

      • Freso
        samj1912: Why? No. Picard should never need root/admin access.
      • 2017-05-09 12932, 2017

      • Sophist_UK
        Hmm - same applies - developers will need separate system-wide directories too.
      • 2017-05-09 12936, 2017

      • samj1912
        well, copy pasting things to the plugin dir seems weird
      • 2017-05-09 12937, 2017

      • zas
        samj1912: no, user downloads always go to user dirs
      • 2017-05-09 12942, 2017

      • Freso
        samj1912: I can update my system-wide plugins by downloading and installing to user folder, and the user folder one will take priority.
      • 2017-05-09 12943, 2017

      • Sophist_UK
        For v1/v2 that is.
      • 2017-05-09 12951, 2017

      • zas
        but they can override system-wide plugins
      • 2017-05-09 12905, 2017

      • arbenina_ joined the channel
      • 2017-05-09 12921, 2017

      • Freso
        samj1912: As a single user you don't manually install things into the system-wide folder.
      • 2017-05-09 12930, 2017

      • Freso
        You use your package manager or something else.
      • 2017-05-09 12945, 2017

      • Sophist_UK
        zas: I see where you are coming from now - re plugin dir search order. Sometimes you may want to disallow a user updating a plugin.
      • 2017-05-09 12929, 2017

      • samj1912
        hmm, well we are going to really niche user cases now, I dont think someone wants to access control their music tagging needs
      • 2017-05-09 12933, 2017

      • zas
        to manage v1/v2 i really think we need to separate clearly all conf files and dirs, but provide an import option for 1.4 to 2.0 transition
      • 2017-05-09 12905, 2017

      • zas
        that's not a niche user case, but usual way of doing things on *nix
      • 2017-05-09 12907, 2017

      • Sophist_UK
        zas: Import or a one-time upgrade code.
      • 2017-05-09 12935, 2017

      • Freso
        ... What would the difference be?
      • 2017-05-09 12908, 2017

      • Sophist_UK
        Import is user initiated and can be done multiple times if you change your 1.4.x config and then want to clone it to your 2.0 config.
      • 2017-05-09 12931, 2017

      • Freso
        Then that's the one that has my vote.
      • 2017-05-09 12932, 2017

      • Sophist_UK
        Upgrade code is seamless for the less technical user.
      • 2017-05-09 12900, 2017

      • Freso
        Esp. if we want to support having people running 1.x and 2.x at the same time.
      • 2017-05-09 12902, 2017

      • zas
        upgrade hooks are a bit hacky, we never really designed this stuff
      • 2017-05-09 12909, 2017

      • Sophist_UK
        Who has 1.4.2 and then installs 2.0 when it is released and never wants to go back.
      • 2017-05-09 12922, 2017

      • zas
        and i think it is ok for small steps but not for major versions changes
      • 2017-05-09 12923, 2017

      • Sophist_UK
        2.0 can be redesigned
      • 2017-05-09 12940, 2017

      • hibiscuskazenek1 joined the channel
      • 2017-05-09 12944, 2017

      • hibiscuskazeneko has quit
      • 2017-05-09 12902, 2017

      • zas
        having a clear separation will ease testing, dev, and free us of a lot of "compatibility" issues
      • 2017-05-09 12917, 2017

      • SothoTalKer
        2.0 is not like 1.5
      • 2017-05-09 12926, 2017

      • Sophist_UK
        But perhaps you are right - better to invest coding time into Import than redesigning the upgrade hooks.
      • 2017-05-09 12941, 2017

      • Mineo
        I have to admit that it's not clear to me what the problem with the upgrade code is
      • 2017-05-09 12945, 2017

      • Freso
        Do we do this by namespacing? E.g., as Sophist_UK has suggested doing plugins/v2/, config-file-v2, etc.?
      • 2017-05-09 12954, 2017

      • SothoTalKer
        just mark 2.0 incompatible with older versions
      • 2017-05-09 12921, 2017

      • Sophist_UK
        SothoTalker: See earlier why that won't work.
      • 2017-05-09 12952, 2017

      • Sophist_UK
        Back in a couple of mins - need a drink (soft).
      • 2017-05-09 12909, 2017

      • samj1912
        so we have 2 options - diff config dirs altogether or just separate plugin dirs
      • 2017-05-09 12937, 2017

      • Freso
        We will be keeping the same config format, right?
      • 2017-05-09 12942, 2017

      • samj1912
        if we only have separate plugin dirs, the config files will be upgraded using the hooks
      • 2017-05-09 12945, 2017

      • Freso
        Ie., .ini files.
      • 2017-05-09 12950, 2017

      • samj1912
        Freso: yup
      • 2017-05-09 12900, 2017

      • samj1912
        I dont think that is bound to change with 2.0
      • 2017-05-09 12903, 2017

      • Freso
        If so, I think just separate plugins dirs would probably be find.
      • 2017-05-09 12905, 2017

      • Freso
        *fine
      • 2017-05-09 12922, 2017

      • Freso
        No, again something that was finally unified on in Picard 1.4. :)
      • 2017-05-09 12938, 2017

      • zas
        Mineo: it is just about removing upgrade hooks from 1.x to 1.y in 2.x
      • 2017-05-09 12913, 2017

      • zas
        my preferrence is to go for a separate conf dir, with major version
      • 2017-05-09 12914, 2017

      • Freso
        So .../plugins/v2 dirs for v2 plugins? How will we notify the user that all their beloved plugins are no longer there?
      • 2017-05-09 12942, 2017

      • samj1912
        Freso: dialog box on a new install?
      • 2017-05-09 12916, 2017

      • Freso
        samj1912: But there should probably also be code to look what plugins they used to have enabled so they can easily find them again.
      • 2017-05-09 12940, 2017

      • samj1912
        will all plugins be ported?
      • 2017-05-09 12958, 2017

      • Freso
        Otherwise they'll have to read the .ini manually since Picard 2.0's config will likely become incompatible with 1.4.x, so they can't just downgrade and doublecheck.
      • 2017-05-09 12912, 2017

      • Sophist_UK
        zas: +1 (because developers want to run 1.4.x and 2.0 in parallel)
      • 2017-05-09 12947, 2017

      • Freso
        If not, then it seems like it's at a point where we might as well start all afresh... maybe the import from old config could be a new plugin...
      • 2017-05-09 12904, 2017

      • Sophist_UK
        Ah - now that's an idea.
      • 2017-05-09 12926, 2017

      • Sophist_UK
        Will we ever want upgrade hook type functionality in the future?
      • 2017-05-09 12931, 2017

      • Freso
        And then you could selectively import CA settings, path/filename ones, tagger scripts, ...
      • 2017-05-09 12939, 2017

      • samj1912
        Sophist_UK: we would
      • 2017-05-09 12950, 2017

      • zas
        Freso: +1
      • 2017-05-09 12901, 2017

      • Freso
        Anyway. Doesn't seem like we're going to reach a consensus on this either right now, and we've been at it for 45 minutes now.
      • 2017-05-09 12901, 2017

      • samj1912
        Freso: +1 from me too
      • 2017-05-09 12903, 2017

      • Sophist_UK
        So we can junk the old hooks? But keep the hooks infrastructure?
      • 2017-05-09 12930, 2017

      • Sophist_UK
        Haven;t we ust reached some sort of consensus?
      • 2017-05-09 12932, 2017

      • zas
        we'll still need upgrade hooks between versions
      • 2017-05-09 12939, 2017

      • Freso
        Sophist_UK: We will definitely want upgrade hook... what zas said. :)
      • 2017-05-09 12947, 2017

      • Mineo
        if the old hooks are removed, will an upgrade from something <1.4 to 2.something still work?
      • 2017-05-09 12955, 2017

      • CatQuest
        damn hi, hello
      • 2017-05-09 12955, 2017

      • Freso
        So.
      • 2017-05-09 12957, 2017

      • samj1912
        nope
      • 2017-05-09 12901, 2017

      • Freso
        I'll try and summarise...
      • 2017-05-09 12912, 2017

      • Freso
        1) Use major version "namespacing" for both config and plugins.
      • 2017-05-09 12941, 2017

      • Freso
        2) Don't manually upgrade 1.x config, instead provide a plugin that allows importing 1.x config to 2.x.
      • 2017-05-09 12900, 2017

      • Freso
        Did I miss something? Is anyone horribly against either?
      • 2017-05-09 12907, 2017

      • samj1912
        +1 from me
      • 2017-05-09 12908, 2017

      • Sophist_UK
        Do we install the upgrade plugin by default with v2?
      • 2017-05-09 12908, 2017

      • Freso
        (And sorry, I forgot CatQuest! Hi!)
      • 2017-05-09 12917, 2017

      • CatQuest
        i missed the meeting :/
      • 2017-05-09 12922, 2017

      • Sophist_UK waves to Catquest
      • 2017-05-09 12928, 2017

      • Freso
        Sophist_UK: Let's leave that for official plugins discussion. ;)
      • 2017-05-09 12929, 2017

      • CatQuest
        hi
      • 2017-05-09 12935, 2017

      • Sophist_UK
        K
      • 2017-05-09 12946, 2017

      • Freso
        (But I think the upgrade/import plugin could be a good candidate for an official one.)
      • 2017-05-09 12954, 2017

      • samj1912
        Freso: are we keeping it to 1hr?
      • 2017-05-09 12959, 2017

      • samj1912
        or do we have more time
      • 2017-05-09 12907, 2017

      • Freso
        samj1912: Preferably, since nothing else has been announced. :)
      • 2017-05-09 12908, 2017

      • CatQuest
        i for one wouldn't mind
      • 2017-05-09 12916, 2017

      • samj1912
        okay
      • 2017-05-09 12923, 2017

      • Sophist_UK
        I am ok with going on longer.
      • 2017-05-09 12932, 2017

      • Freso
        Mineo, zas, Sophist_UK: Half an hour extra maybe?
      • 2017-05-09 12933, 2017

      • Mineo
        Freso, should 2) be "don't automatically [...]"?
      • 2017-05-09 12943, 2017

      • Mineo
        sure
      • 2017-05-09 12945, 2017

      • zas
        Freso: ok for me
      • 2017-05-09 12946, 2017

      • Freso
        Mineo: Eh, yes, exactly that. :p
      • 2017-05-09 12951, 2017

      • Freso
        Alright. :)
      • 2017-05-09 12956, 2017

      • Sophist_UK
        +1
      • 2017-05-09 12908, 2017

      • Mineo
        do we expect the config to be so dramatically different that this can't be done automatically?
      • 2017-05-09 12911, 2017

      • Freso
        samj1912: ~40 more minutes. ;)
      • 2017-05-09 12943, 2017

      • CatQuest
        sorry to ask this, but could someone give me a quick recap (in a pm or osmething)
      • 2017-05-09 12945, 2017

      • Freso
        Mineo: I guess we just don't know yet. :) Perhaps this is all premature. I think the important decision is the namespacing.
      • 2017-05-09 12955, 2017

      • zas
        that^^
      • 2017-05-09 12929, 2017

      • Sophist_UK
        Ditto
      • 2017-05-09 12932, 2017

      • samj1912
        ok so we have reached a consensus with this issue?
      • 2017-05-09 12934, 2017

      • Freso
        CatQuest: We're just about to move on to the next (sub?)topic, so you'll be able to attend all of that. :)
      • 2017-05-09 12940, 2017

      • CatQuest
        sweet!
      • 2017-05-09 12941, 2017

      • Freso
        I think so.
      • 2017-05-09 12945, 2017

      • samj1912
        cool
      • 2017-05-09 12952, 2017

      • Freso
        No one objected to my summary at least. We can revisit 2) later.
      • 2017-05-09 12907, 2017

      • Freso
        samj1912: More plugins talk?
      • 2017-05-09 12911, 2017

      • CatQuest has no idea wtf "namespacing" refers to here :/
      • 2017-05-09 12913, 2017

      • Sophist_UK
        Lets call it a draft decision and see if anyone objects.
      • 2017-05-09 12919, 2017

      • samj1912
        I do have a few more plugin related topics
      • 2017-05-09 12932, 2017

      • Sophist_UK
        CatQuest: Separate directories for v1 and v2 config / plugins
      • 2017-05-09 12941, 2017

      • CatQuest
        i think i'm for that
      • 2017-05-09 12942, 2017

      • samj1912
        related to testing and the generation script (I think we left this one in the middle)
      • 2017-05-09 12959, 2017

      • CatQuest
        (wit a possible ability to "import" settings)
      • 2017-05-09 12914, 2017

      • Sophist_UK
        CatQuest: Yes.
      • 2017-05-09 12921, 2017

      • CatQuest
        🖎
      • 2017-05-09 12923, 2017

      • Freso
        samj1912: I was thinking it might be nice to do maybe threading or distribution, since I think one of those would be an "easy" one to tackle on top of a couple of heavy ones. :) But sure, let's do another plugins round first, while we have the time!
      • 2017-05-09 12944, 2017

      • samj1912
        well testing should be "easy"
      • 2017-05-09 12950, 2017

      • Sophist_UK
        Lets finish the generation script first
      • 2017-05-09 12951, 2017

      • Freso
        Let's do that. ;)
      • 2017-05-09 12957, 2017

      • Sophist_UK
        Oh = ok
      • 2017-05-09 12900, 2017

      • samj1912
        I propose a simple test_plugin_name file inside the plugin dir
      • 2017-05-09 12920, 2017

      • Freso
        So e.g., addrelease/test_addrelease.py?
      • 2017-05-09 12922, 2017

      • Freso
        +1 from me.
      • 2017-05-09 12924, 2017

      • samj1912
        yup
      • 2017-05-09 12932, 2017

      • CatQuest
        what would this be for? uh testing?
      • 2017-05-09 12940, 2017

      • Freso
        That was what I was going to go for too. :)
      • 2017-05-09 12955, 2017

      • Sophist_UK
        +1
      • 2017-05-09 12900, 2017

      • Freso
        CatQuest: Make (more/some) regressions preventable.
      • 2017-05-09 12912, 2017

      • samj1912
        and a script in the base dir to run all plugin tests
      • 2017-05-09 12913, 2017

      • CatQuest
        aha! +1 then
      • 2017-05-09 12914, 2017

      • Freso
        Only really relevant for developers.
      • 2017-05-09 12921, 2017

      • samj1912
        so this works for everyone?
      • 2017-05-09 12943, 2017

      • Freso
        samj1912: Most testing frameworks allow automated test discovery, so I don't think we'd even need a custom script.
      • 2017-05-09 12951, 2017

      • Mineo
        if at all possible, please just use the standard... what Freso said
      • 2017-05-09 12952, 2017

      • lazka joined the channel
      • 2017-05-09 12901, 2017

      • samj1912
        okay 👍
      • 2017-05-09 12903, 2017

      • Sophist_UK
        CatQuest: Unit testing internal functions and possibly overall functinality, with a test framework implemented for local testing by developers and for travis.
      • 2017-05-09 12927, 2017

      • zas
        +1
      • 2017-05-09 12927, 2017

      • CatQuest
        it seems weird tha that is not already a part of it :o
      • 2017-05-09 12937, 2017

      • Freso
        samj1912: Also, FWIW, I would like to write some tests for addrelease, so if you start on making tests, please leave that one to last to give me a chance. :D
      • 2017-05-09 12951, 2017

      • Freso
        CatQuest: It's old code, yo.
      • 2017-05-09 12951, 2017

      • samj1912
        okay :D
      • 2017-05-09 12958, 2017

      • CatQuest
        :P
      • 2017-05-09 12910, 2017

      • Freso
        Okay, yes, that was an easy topic.
      • 2017-05-09 12913, 2017

      • Freso
        !next
      • 2017-05-09 12916, 2017

      • Sophist_UK
        Generation?
      • 2017-05-09 12918, 2017

      • CatQuest
        oh I get it's it's not "test script" it's test (this) script
      • 2017-05-09 12920, 2017

      • samj1912
        about the generation script