Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

On Unix like OSs, look for sqlpackage in directories specified in $PATH #2700

Conversation

nick-gravgaard
Copy link
Contributor

@nick-gravgaard nick-gravgaard commented Sep 9, 2022

This PR addresses issue #2701 of sqlpackage not existing in the same place on MacOS and Linux distros by following the canonical Unix practice of searching the directories specified by the PATH environment variable instead of using a hard-coded path.

@nick-gravgaard nick-gravgaard changed the title On Unix like OSs, look for sqlpackage in directories specified in PATH On Unixlike OSs, look for sqlpackage in directories specified in $PATH Sep 10, 2022
@nick-gravgaard nick-gravgaard changed the title On Unixlike OSs, look for sqlpackage in directories specified in $PATH On Unix like OSs, look for sqlpackage in directories specified in $PATH Sep 10, 2022
@mattgallagher92
Copy link

I've tested this out in my Ubuntu environment, where I have a symlink in /usr/local/bin to my sqlpackage install location, by running the expression Nick has added in F# interactive. It resolves correctly:

    Environment.pathDirectories
    |> Seq.map (fun dir -> !!(dir </> "sqlpackage"))
    |> Seq.concat
    |> Seq.map (fun path -> path, 15)

val it: seq<string * int> = seq [("/usr/local/bin/sqlpackage", 15)]

@yazeedobaid
Copy link
Collaborator

Thanks for the PR,
I would like to suggest keeping both ways. The old hard-coded way and the commonplace (best practice) as you mentioned. From what I see, now it will search in environment variables only. I'm thinking about a case when a user doesn't have SQL Package in the environment variables but is added to the directory that was hard-coded.

@yazeedobaid
Copy link
Collaborator

@mattgallagher92 thanks for testing and confirming the fix

@nick-gravgaard nick-gravgaard force-pushed the use-path-for-sqlpackage-on-unix branch from cdb5c3e to d3accd9 Compare September 12, 2022 18:29
@nick-gravgaard nick-gravgaard force-pushed the use-path-for-sqlpackage-on-unix branch from d3accd9 to f275631 Compare September 12, 2022 18:39
@nick-gravgaard
Copy link
Contributor Author

nick-gravgaard commented Sep 12, 2022

Thanks for the feedback @yazeedobaid. I was going to argue that it should be the user's responsibility to ensure their $PATH includes the directory sqlpackage is in, but if we don't do something like you suggest we risk breaking previously working setups. So I agree with you and have pushed up a new commit. First it checks $PATH, falling back to /usr/local/bin (where it currently lives on MacOS), and finally /usr/bin (where it currently lives on the Linux distros I know about).

I think this order is correct. The directories in $PATH should be checked first because that's where users can define their own locations for binaries. The next place should be /usr/local/bin because that's the location for normal user binaries not managed by the distro's package manager, eg. locally compiled packages. Finally we check /usr/bin because that's where distro-managed normal user binaries go.

Having /usr/local/bin before /usr/bin also matches the order in my $PATH as set by my distro, which reinforces my belief this is the most sensible order.

@yazeedobaid yazeedobaid merged commit effecbf into fsprojects:release/next Oct 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants