Symlink executables in ~/bin

[derEremit]

code like atom supports a workflow for editing a project by starting in project root with code .

for that Code should automatically symlinked to ~/bin/code or /usr/local/bin/code

see: https://code.visualstudio.com/Docs/setup

[didrocks]

Thanks for opening this wishlist.

Adding the tools to the user's path (note especially ~/bin/code) is something that is already in discussion in other bug reports. There are pros and cons for each. I renamed your bug report as this isn't linked to visual studio code, but the tool in general (if people want to start it from the command line). I let the bug opened for more discussion.

[ojsheikh]

I think this will be a nice feature - especially with text editors and launching firefox-dev with specific profiles.

If this is to be added, how should we go about it? Quite a few frameworks provide a large number of executables, e.g. Golang provides 'go', 'godoc' and 'gofmt'. For such frameworks umake currently adds the folder with the executables to $PATH in ~/.(z)profile. Should we continue using that method or switch to creating symbolic links for all executables in the folder? Some installers may not provide an executable only 'bin' folder, for those I am guessing only the primary executable should be symlinked? Each symbolic link created would have to be recorded in ~/.config/umake for removal later.

Previous discussion on this matter was at #81.

[didrocks]

The more I'm thinking about it, the more I'm unconvinced that we can implement that well.

As you told, we need to look and list all binaries for any given framework. For language frameworks in particular have many executable. Also, imagine that we let autoupdating some IDEs, this one providing new or changed paths (and this autoupdate being independent of Ubuntu Make), there are quite a lot of chances we have to rebuild in this .bin directory.

I think this will introduce more complexities that it will fix.

[LyzardKing]

If we add the folder with the binary to PATH it should be possible to run something like "code ." Being that the folders could have more executables (example in eclipse there is icon.xpm) we could create a directory in ./local/share/umake (called bin ?), add that to PATH and symlink the binaries that we use in the .desktop creation in that folder.

[didrocks]

The proposal here is exactly matching what you tell, just replace your "~/.local/share/umake/bin" with "~/.bin". But then, there is the numerous upgrade issues I mentioned above.

[LyzardKing]

Do the auto-updates edit the .desktop file if the binary location changes?

[didrocks]

No, and it's indeed one of the issue (if people use autoupdate). I doubt though a lot of desktop UI tools would change their running binary command. I'm way more concerned about the various CLI tools like the android sdk one that are added to path, where you have 20 or so runnable commands, which might move, change and so on…

[LyzardKing]

editors should not have this problem. Since we're creating the .desktop with the path to an executable we could link that. I wouldn't do anything for the language frameworks (they already get added to path). I'm not sure how the android framework works. This would be a solution for the ide and games frameworks.

[didrocks]

Ok, so that would basically be for frameworks where we don't really set a PATH (and where we add an explicit exec one). That way, with that clear separation, that could work as this use-case is only for some "stars" executable which shouldn't change much.

[LyzardKing]

yes, that was my idea. I can start setting that up if you think it's worth it

[didrocks]

I think we need to investigate a little bit more before rushing into this. For instance, take the "eclipse" ide, they all have the same "eclipse" short name for executable, and that wouldn't work well for such things. We can default to the desktop filename which we need to keep unique as it's the only things we want to symlink in that path anyway, but that means those would be rather shell wrapper scripts, adding the right options and so on.

I guess if you can spend some time explorating that, it would be awesome!

[LyzardKing]

I didn't think about the eclipse case. That's true...(they had the same issue with the icon). We could use like you said the .desktop name (eclipse-java, eclipse-php, jetbrains-idea, visual-studio-code, ...). for instance: os.symlink(os.path.join(exec_path), os.path.join('~', '.bin', 'desktop_filename.split('.')[0]'))

[didrocks]

we might check if we don't want to add any options to the command line by default, but yeah, if there is none to add, true.

I guess new tests and modifying existing ones about this will be required :)

[LyzardKing]

I think most executables are fine to run as they are, but we can check, It would be nice to have some feedback for that. Regarding the tests, we can use something like the is_in_path. We would have to add the mock for the medium tests then...

[didrocks]

yeah, is_in_path sounds good!

I don't think the medium tests mock needs to be added, as the executables linked to .desktop file should be already present :)

[LyzardKing]

Even better :) I'm not sure I can do much this week, but I can at least test this out. It should be fairly generic to be able to replicate easily once it works.

[didrocks]

No worry and no hurry, I don't see that as a high priority anyway :) Thanksf or looking into it though!

[ojsheikh]

I had not considered self updating frameworks and I agree that those could be problematic. I suppose umake will continue with using $PATH manipulation for cli utilities at least. Thanks for picking it up for single executable frameworks however :)

I believe the private bin directory on ubuntu is ~/bin not ~/.bin though.

[marcinant]

:+1:

[didrocks]

In master now, thanks to @LyzardKing!