sh 1.14.3 breaks isinstance(sh.command_name, sh.Command)

[Sam Hartman]

>>> from sh import Command, ls
>>> isinstance(ls, Command)
False
>>> import sh
>>> sh.__version__
'1.14.3'

sh.ls will be an instance of a class called Command that has the same code as sh.Command, but has a different id/memory location.
This works correctly in 1.14.2.

I had a wrapper around sh that used isinstance(foo, Command) to see if it was a command, or if it was a special object like ErrorReturnCode.
It turns out I can simplify my code by using execution contexts, but I think it's reasonable to be able to check if something is a Command.

The problem is introduced by the logic in the SelfImporter that copies the Command class to add baked arguments.

sh 2.0.6 does not suffer from this problem.

I'm not entirely sure what a good solution here is. If there were a way to get resolve_command to use the new command class somehow? Or alternatively a metaclass with an instancecheck method?

I care a lot less about this issue if it's going to be limited to sh 1.x releases than if future versions of sh 2.x will have the same issue.

Thanks for your hard work and consideration.

[Andrew]

Thanks for the report. The recommendation here is to upgrade to latest if possible. I don't foresee backporting bugfixes unless they address security issues. There is a migration doc that should help if there are old behaviors that you want to preserve.

[Sam Hartman]

>>>> "Andrew" == Andrew ***@***.***> writes:

Andrew> Thanks for the report. The recommendation here is to upgrade Andrew> to latest if possible. I don't foresee backporting bugfixes Andrew> unless they address security issues. Understood. The only reason I brought it up is that it broke between 1.14.2 and 1.14.3. I.E. it was a bug introduced on an old branch.