Do not use deprecated find_executable

[ricardoV94]

Closes #997

[Ch0ronomato]

This might be slightly different between windows v linux v unix.

Also does shutil reference any aliases? Is that necessary?

[Ch0ronomato]

(not blocking just curious)

[ricardoV94]

No idea tbh, I only followed the deprecation recommendation

[lucianopaz]

I'll have to check how it handles aliases, but shutil.which is supposed to handle symlinks besides regular files, and it should also be able to work with executable extensions. The difference between path handling between windows and unix systems doesn't look to be too bad.

[lucianopaz]

LGTM. Thanks @ricardoV94

[lucianopaz]

I'll have to check how it handles aliases, but shutil.which is supposed to handle symlinks besides regular files, and it should also be able to work with executable extensions. The difference between path handling between windows and unix systems doesn't look to be too bad.

[lucianopaz]

Oops, I hadn't looked at the failed tests. I'll have to dig a bit deeper into the difference between shutil.which and find_executables. If we're lucky, it might just be a simple formatting problem that we need to iron out between the outputs of the two functions.

[ricardoV94]

Someone mentioned this failure in another PR so it might be unrelated actually

[lucianopaz]

Someone mentioned this failure in another PR so it might be unrelated actually

Yeah, it looks like it started at some point in the last three days and it's hitting multiple PRs. It must be some environment change in the github actions container.

[ricardoV94]

Someone mentioned this failure in another PR so it might be unrelated actually

Yeah, it looks like it started at some point in the last three days and it's hitting multiple PRs. It must be some environment change in the github actions container.

Any idea how to go about fixing it?

[lucianopaz]

Any idea how to go about fixing it?

It’s hard without a local env that fails. It could be possible to open a dummy PR and try to debug via the CI workflows. These failures in the blas configuration are just a mess. I don’t know why it was originally programmed in a way that yields an invalid configuration by default when things fail during the blas checks

[ricardoV94]

I don’t know why it was originally programmed in a way that yields an invalid configuration by default when things fail during the blas checks

What do you mean? On the CI we just want to make sure we are running against BLAS

[maresb]

Not sure about links but LGTM

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.74%. Comparing base (3e55a20) to head (a9ed0f9).
Report is 8 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1000   +/-   ##
=======================================
  Coverage   81.74%   81.74%           
=======================================
  Files         183      183           
  Lines       47724    47733    +9     
  Branches    11616    11616           
=======================================
+ Hits        39011    39020    +9     
- Misses       6518     6520    +2     
+ Partials     2195     2193    -2     

Files with missing lines	Coverage Δ
pytensor/configdefaults.py	71.61% <100.00%> (ø)

... and 2 files with indirect coverage changes