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

installer upgrades #512

Merged
merged 40 commits into from
Jun 20, 2019
Merged

installer upgrades #512

merged 40 commits into from
Jun 20, 2019

Conversation

bartlomieju
Copy link
Member

@bartlomieju bartlomieju commented Jun 19, 2019

Closes #497.
Closes #501

Blocked on #509.

This PR:

  • splits installer into separate files leaving flag parsing in installer/mod.ts
  • removes uninstall command
  • adds --reload to deno fetch - this ensures that subsequent installation will upgrade executable
  • fixes shebang missing !
  • fixes prompt on subsequent installation
  • supports -d/--dir parameter for custom installation directory

After we land this PR I'll upgrade deno install.

@bartlomieju bartlomieju changed the title chore: split installer installer upgrades Jun 19, 2019
@bartlomieju
Copy link
Member Author

@axetroy take a look - looks like I fixed problem in Windows tests.

@ry
Copy link
Member

ry commented Jun 20, 2019

I think that uninstall command is superfluous.

I agree. For myself at least “rm $(which file_server)” works

(Brevity due to phone)

@axetroy
Copy link
Contributor

axetroy commented Jun 20, 2019

I think that uninstall command is superfluous.

agree with this.

but I don't think allow different installation directories is a good idea.

This may cause some module to induce users to install in /usr/local/bin instead of the default $HOME/.deno/bin

It makes difficult to manage the installed module.

example1: if the user reinstalls in different directories. There are two identical scripts in the $PATH, how to deal with this?

example2: if there is a conflict with the native command, for example, there is a file ls under /usr/local/bin. At this time, the user installs the ls module to /usr/local/bin, what should I do?

At least for the current stage, I disapprove.

The solution to allowing different installation directories

If the user wants to install in /usr/local/bin, he can move the script manually.

@bartlomieju
Copy link
Member Author

This may cause some module to induce users to install in /usr/local/bin instead of the default $HOME/.deno/bin

It makes difficult to manage the installed module.

You have to explicitly tell installer that you want to install somewhere else (eg. --dir /usr/local/bin), installed modules won't have ability to decide where to install themselves.

example1: if the user reinstalls in different directories. There are two identical scripts in the $PATH, how to deal with this?

example2: if there is a conflict with the native command, for example, there is a file ls under /usr/local/bin. At this time, the user installs the ls module to /usr/local/bin, what should I do?

Your shell deals with that, nothing prevents you from doing exactly these things right now.

Some people might want to keep all executable files in single place and don't want to add ~/.deno/bin to their PATH

@axetroy
Copy link
Contributor

axetroy commented Jun 20, 2019

My point is to keep the computer as simple as possible.

When I need deno, I will go to $HOME/.deno to find the file.
When I don't need deno or want to uninstall it, just remove $HOME/.deno, except for the cache. No residual files.

make it clean and don't mess up your computer.

@ry
Copy link
Member

ry commented Jun 20, 2019

@axetroy I'm of your opinion too I prefer everything located in ~/.deno, but I think a flag to specify the directory is fine...

(I kind of wish the cache was still there too...)

@bartlomieju
Copy link
Member Author

Okay so I added -d/--dir flag - it tells where to put executable. This said, installed executable still uses default deno cache directory.

(I kind of wish the cache was still there too...)

Maybe we should add DENO_DIR to generated executable file - then each installed module is isolated and can be simply upgraded. WDYT?

@ry
Copy link
Member

ry commented Jun 20, 2019

Maybe we should add DENO_DIR to generated executable file - then each installed module is isolated and can be simply upgraded. WDYT?

Eh.. Idk. I'd prefer the DENO_DIR be controlled by the caller.

@bartlomieju
Copy link
Member Author

Eh.. Idk. I'd prefer the DENO_DIR be controlled by the caller.

Let's tackle that later. This PR should be landable as is. PTAL and review

Copy link
Member

@ry ry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good - just one thing...


OPTIONS:
-d, --dir <PATH> Installation directory path (defaults to ~/.deno/bin)
`);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wish the flags module was more like Go's... This would be generated automatically.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I was looking at porting one of more advanced CLI modules from node:

But I might as well look into https://golang.org/pkg/flag/

installer/mod.ts Outdated Show resolved Hide resolved
Copy link
Member

@ry ry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ry
Copy link
Member

ry commented Jun 20, 2019

@bartlomieju Can you draft a commit message please?

@bartlomieju
Copy link
Member Author

@ry

Upgrade installer

  • remove uninstall command
  • add --reload to deno fetch - to ensure subsequent installation upgrades script and deps
  • fix executable shebang
  • fix prompt for subsequent installation
  • support custom installation dir via -d/--dir flag

@ry ry merged commit b13441f into denoland:master Jun 20, 2019
@bartlomieju bartlomieju deleted the split_installer branch June 20, 2019 14:57
axetroy added a commit to axetroy/deno_std that referenced this pull request Jun 24, 2019
add test case for reading code from stdin and format

update

update

update

update

update

update

update

update

update

update

update

update

update

update

update

improve installer (denoland#512)

- remove uninstall command
- add --reload to deno fetch - to ensure subsequent installation
  upgrades script and deps
- fix executable shebang
- fix prompt for subsequent installation
- support custom installation dir via -d/--dir flag

typo (denoland#515)

bundle/run handles Deno.args better. (denoland#514)

fix: pin eslint version for CI (denoland#518)

typescript-eslint/typescript-eslint#637

feat: add catjson example (denoland#517)

file server should order filenames (denoland#511)

update

update

update

update

update

update

update

update

update

update
ry pushed a commit to ry/deno that referenced this pull request Oct 9, 2019
- remove uninstall command
- add --reload to deno fetch - to ensure subsequent installation 
  upgrades script and deps
- fix executable shebang
- fix prompt for subsequent installation
- support custom installation dir via -d/--dir flag
Original: denoland/std@b13441f
inverted-capital pushed a commit to dreamcatcher-tech/napps that referenced this pull request Oct 24, 2024
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.

installer: installed module can not run in fish terminal Upgrades to installer
3 participants