Feat/test harness

[tdejager]

This adds the ability to write integration tests, that do actual pixi commands to run the integration test. A PixiController and convenience methods have been added to test these things. Also the integration tests can become pretty expensive so you can use the slow_integration_tests feature to only run these in CI by default. On the commandline one can use cargo t --all-features to test it manually,.

Before merge:

• Merge and integrate: refactor to install command and add manifest path #135 so that do not need to set the current working dir everywhere. This prohibits parallel testing.

After merge:

• Make a builder to easily build RepoData @baszalmstra will make a seperate PR and we can use that to test more advanced features a bit faster.

[wolfv]

is this cleared up now?

[wolfv]

Looks good to me! Needs a rebase?

[baszalmstra]

I think it would be nice if you can pass the Args object to the different functions. That would make it easier to call the function with specific optional arguments. E.g. by default you'd do:

pixi.init(Default::default())

but if you want to use some obscure argument you can do:

pixi.init(Args {
  some_obscure_arg: 42,
  .. Default::default()
})

[tdejager]

Yeah but from the cli you do not want to pass in the project by default right? That’s why I split up the functions because it accepts a specific project to work from

…

On Fri, 23 Jun 2023 at 17:05, Bas Zalmstra ***@***.***> wrote: I think it would be nice if you can pass the Args object to the different functions. That would make it easier to call the function with specific optional arguments. E.g. by default you'd do: pixi.init(Default::default()) but if you want to use some obscure argument you can do: pixi.init(Args { some_obscure_arg: 42, .. Default::default() }) — Reply to this email directly, view it on GitHub <#138 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADF4XRTVPE3R5HXWICGRI3XMWWE7ANCNFSM6AAAAAAZRQSFFY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[tdejager]

Seeing as the Arg structure is coupled to the CLI functions

…

On Fri, 23 Jun 2023 at 17:57, Tim de Jager ***@***.***> wrote: Yeah but from the cli you do not want to pass in the project by default right? That’s why I split up the functions because it accepts a specific project to work from On Fri, 23 Jun 2023 at 17:05, Bas Zalmstra ***@***.***> wrote: > I think it would be nice if you can pass the Args object to the > different functions. That would make it easier to call the function with > specific optional arguments. E.g. by default you'd do: > > pixi.init(Default::default()) > > but if you want to use some obscure argument you can do: > > pixi.init(Args { > some_obscure_arg: 42, > .. Default::default() > }) > > — > Reply to this email directly, view it on GitHub > <#138 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AADF4XRTVPE3R5HXWICGRI3XMWWE7ANCNFSM6AAAAAAZRQSFFY> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[baszalmstra]

I think that can still be achieved through the manifest_path argument. If the passed in args are None the PixiControl overwrites it, otherwise it leaves it intact. The advantage of directly using the Args for the command is that we stay much closer to the interface the CLI command exposes.

Maybe it's also fine if the project is loaded on demand when using PixiControl::project instead of keeping a copy around that you need to update manually for each function you add.

But concretely I ran into this issue because I would like to add a channel argument to the CLI to initialize the project with the specified channel instead of conda-forge. I can now either do this by adding an additional argument to init, which I only rarely need, or by creating another Args struct that is converted to the init::Args or some other convoluted way. It would be much simpler if I could just pass in:

pixi.init(init::Args { channel: .., Default::default() })

Let me know what you think!

[tdejager]

Surreee let me give it a go!

[tdejager]

One question, regarding the run command with the test harness you want to wait and collect the output and from the CLI interface you never want to do this. So it would be weird to add it to Args. I think.