Test executable is available / Test pip packages

[rgarrigue]

Hello

I guess this is a feature requests since I couldn't find this in the doc : I'ld like to be able to test for both

• If an executable exists. I'm testing cross distro, defining the package name is tricky at best. But I could just test a "pip" command, if rc == 0 that's fine by me.

• And if pip package are installed, like testinfra does : http://testinfra.readthedocs.io/en/latest/modules.html#pippackage

Cheers, Rémy

[aelsabbahy]

For now use command to test pip. I'm not too interested in trying to support non-distro package managers (or service monitors).

The executable one is interesting, I'll have to think on that one a bit more. It would essentially be a test to see if binary is in your PATH? Or are you trying to check if an arbitrary file is executable?

[rgarrigue]

This is how I'm seeing this

executable:
    binary: "pip"
    path: "/home/user/bin"      # default = system path
    version: "3.1.8"                 # default = do not check version
    version_switch: "-v"          # default value --version

• First, you check if there's a binary answering to "pip" in the PATH
• Second, you check if the binary still got a rc == 0 when you execute "${binary} ${version_switch}
• Third, check if ${version} in ${output}

It's a simple scenario but if everything is green, that means a lot for the user : exec is here, it's not breaking over a seg fault or missing deps...

[aelsabbahy]

Yeah, for that use-case I think command is sufficient enough and provides more flexibility:

command:
  pip --version:
    exit-status: 0
    stdout:
    - 9.0.1
    stderr: []
    timeout: 10000

[pedroMMM]

@aelsabbahy I added support for pip on my fork as another package implementation. Would you accept the PR?

[aelsabbahy]

@pedroMMM I'm leaning pretty heavly against adding pip or any application level package manager for now. https://en.wikipedia.org/wiki/List_of_software_package_management_systems#Application-level_Dependency_managers

Seems like it would open up a can of worms: npm, gem, pip, pipx, cpan, etc. They each may introduce their own packaging concepts (e.g. virtualenvironments).

I would rather see if there are enhancements to command resource that make it easier for a user to check this themselves. Or add a way in Goss for users to define a re-usable test using commands.

I'm open to discussing this further, just being clear up front for my bias and reasons for my bias.

[pedroMMM]

@aelsabbahy I understand, I have been considering similar implications.

Originally, I was imagining adding Pip (and others) to the package resource but then I began thinking of the pollution it would bring, especially when using add. At the moment I am considering each of them should be an independent resource while sharing some code behind the scenes (if it proves to be practical).

This would let the community add the application-level package managers they wish, while it been mostly self-contained. The details of implementation like virtual environments would be encapsulated in the specific resource created by the community.

This would also enable maintainers to not have to consider Pip when making changes to the package resource.

That said I agree on your bias against application-level package managers but I have to maintain some tooling at my current position that requires Pip packages while I keep working on evangelizing the team on Go-based tooling. I know that I am not alone on this and it could benefit the community while minimizing the blast radius.

I am also curious about your ideas to enhance command.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.