allows setting an output path.

[yggdrasil75]

poorly named branch. this allows setting a specific output path for a given axisvalue instead of using the axisvalue name. still uses name if no path provided.

[yggdrasil75]

this fixes #50 as well.

[yggdrasil75]

fixed all 3. still dont get it though. but did it anyway.

[yggdrasil75]

oh. just noticed that this uses the wrong path in the html/javascript. let me try figuring that out.

[mcmonkey4eva]

Regarding the actual functional purpose of this PR: Can you give an example of a case where you would want to set the path value, but where updating the key would not be sufficient?

[yggdrasil75]

piecemeal skipping with batches and various output resolutions was the intended goal. on 1.5 you can easily do larger batches for better performance, but on xl the large batches have basically no benefit.

axis:
    model:
        title: models
        values:
            1.5:
                title: old version
                params:
                    model: sd1.5.safetensors
            xl:
                title: new version
                params:
                    model: sdxl.safetensors

    batching:
        title: batch sizes
        values:
            512xl:
                title: 512x
                path: 512
                skip:
                    - old version
                params:
                    batchsize: 4
            512old:
                title: 512x
                path: 512
                skip:
                    - new version
                params:
                    batchsize: 36

in addition, it can be useful if you want to keep an axisvalues key, but change the params. that isnt user-facing once done, but still may be useful.

[yggdrasil75]

this looks correct now, I think. I am not seeing any issues after making these changes anymore.

[mcmonkey4eva]

Unresolved issues:

• This has no functional purpose on its own. It only is relevant once a separate change is made, which should have been done first naturally. This relates to the topic of the other PRs, at least one of which explicitly lacks any clear purpose you could define (the negative prompt replace that doesn't add unique capabilities, that you don't use, that nobody has ever requested).
• No this doesn't affect issue 50, that's separate.
• The issues I found while testing, alongside the issues brought up with the other PRs (eg the negative prompt replace PR that would error immediately on usage due to a missing variable), imply to me that you're not testing these PRs, or at least not testing them thoroughly. When you're writing code for more than just yourself to use, you must validate both that the code itself works, and further that every possible use case works as intended (eg here there were immediate failures on trying to operate any grid that didn't have custom paths assigned)

---

Issues I went ahead and resolved myself by the commits above:

• There were multiple basic formatting mistakes.
• exported_paths being a list meant it could potentially be a performance issue on large grids (the in check is linear, making it O(n^2) - changing it to a dict cures that)
• path was never set on axis values that aren't defined in block format, breaking the majority of grids entirely
• exported_paths was local to an axis, but was defined global to the grid - ie, if multiple values on different axes had the same keys (which they do by default!) the grid would fail to export values entirely, leaving grids nonfunctional.

---

With the code issues fixed, I'm going to merge this in now, however I urge you to think about the topic of testing well, and the topic of defining a clear purpose for the code you write.

[mcmonkey4eva]

ps you appear to have authored the commits from the account @yggdrasil7557 rather than your main one? Not sure what's up with that, probably you'll want to check your git settings.

also ps re the commit titled I still dont get it. it does the same thing. I understand that seems weird but I promise there's a good reason, if you keep on the programming path eventually you'll wind up learning about the hellish rabbit hole of Windows-Linux intercompatibility and learn why things like that are important, and why older APIs like os.path get them wrong (and newer APIs sometimes do better, iirc python's pathlib is a bit better at handling the edge cases)