I assume on that spreadsheet "included" means, it exists in the repo, right?

@haf-afa is it possible you can test the fix please? Without your help, it's unlikely we'll be able to figure this out. I'm attaching the steps below.

I have a suspicion that symlinks won't work on a NAS filesystem where your %HOME% resides.

To test the fix in #375, do these steps:

1. download krew.exe.zip and extract it to get a krew.exe out
2. download krew.yaml.txt and rename it to krew.yaml
3. download krew.tar.gz
4. run: krew.exe --manifest=krew.yaml --archive=krew.tar.gz
5. if it fails, delete %HOME%\.krew and re-run the command above with flag -v=5 and copy its output here

🐛 Describe the bug
A clear and concise description of what the bug is. You are always welcome to check the Troubleshooting section before filing the ticket.

🌴 Visual Studio Code Version : 1.40.0 🌴 Code Settings Sync Version : 3.4.3 🌴 Standard or Insiders : standard 🌴 Portable or Installed : installed 🌴 OSS or Official Build : official 🌴 Operating System : macOS 🌴 Occurs On: Configuring 🌴 Proxy Enabled: No 🌴 Gist Id: c20f6d5380818c9d002692d1f2a20900

I just installed and got this list of Gists, it goes as old as 17 months.

However my most recently updated gist that shows on gist.github.com doesn't show up in that list:

My gist ID (c20f6d538....) is not in the list for some reason –and there's no way to input an existing ID. :( The only option is:

SKIP (NEW ONE WILL BE CREATED UPON FIRST UPLOAD)

I have to choose this. Next, since I kept the "Welcome" screen on, I can just enter my Gist ID there.

I think this experience is buggy.

Sidenote: BTW if the Welcome screen doesn't fit to a screen, since it doesn't have a scrollbar, a user can't see the contents of that page fully

/approve

Personally I don’t want to get to package management business for Linux, the space is vastly segmented and I don’t use Linux myself. I’ve personally built a cross-platform package manager (see: krew.dev) so this is way too much for me to support reliably.

Although if there’s someone willing to sign up to do this in the long term (especially with something like fpm, that handles multiple pkg managers at once) I’d be happier.

Ensure LICENSE is part of the release bundle for krew itself, and is copied out to the resulting installation directory.

I'll remove the fix myself I think. I don't have multiple real partitions on windows to test this but I think I can do

• plug in SD card to E: (FAT)
• set TMP=E:\tmp
• set KREW_ROOT=C:\users\ahmetb.krew
• krew install
  • symlink to c:\

this would ensure we try to os.Rename files from e:\ to c:, which would fall back to copying. At the end it would symlink to C:\ (NTFS) which is allowed.

/retitle Improve logic to determine if receipts migration is necessary

/hold cancel

/lgtm /approve thanks!

60 plugins! 🚀

/assign @corneliusweig

Precisely, we need to get ahead of the growth here. I feel like there will be some manual work involved. We should probably open a mega issue with all plugins and keep track of the fixes very soon.

For that reason, I think a new license field in the manifest may be the better option.

Yeah but LICENSE file is not really special. Similarly, they might have multiple licenses, dependency licenses, other files like {changelogs,authors}.txt that they might need to ship. I recommend we don't get into that business.

I'm currently -1 for introducing a new field, just for the license.

It's clear to me (1) we need to work with repo authors, maybe even make PRs to them ourselves, and it'll be a team effort (2) make this a requirement from now on (update docs, PR templates etc).

What I'm more unclear about is which one of these we should do:

• copy certain files (license, copying, ...) from the archive (root, or maybe 1-level deep) automatically out to installDir
• explicitly require every plugin to copy its LICENSE and similar files in files:.

this is not very realistic since it created dirs under bin/ let's just ad /konfig.sh

also if "konfig" the word isn't relevant, let's say "foo", (ditto below)

but it seems like this has simplified the tests a good deal.

It appears like Go actually has support for the SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag out of the box in os.Symlink. https://golang.org/src/os/file_windows.go#L386

Sounded promising, right? Here comes the dumbest part: SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE only works if Developer Mode is enabled, so, for anyone distributing client software (like krew), it's useless.

/area platform/windows /priority P2 /kind bug

Right now Windows user (1) installing krew, or (2) installing plugins with Krew needs to be in a "Run as Administrator" shell (cmd, or powershell). Otherwise they'll get an error like:

W1031 07:54:50.430335 11588 install.go:127] failed to install plugin "krew": install failed: failed to link installed plugin: failed to create a symlink form "C:\Users\z\.krew\bin" to "C:\Users\z\.krew\bin\kubectl-krew.exe": symlink C:\Users\z.krew\store\krew\v0.3.1\krew.exe C:\Users\z.krew\bin\kubectl-krew.exe: A required privilege is not held by the client.

This is bad for user experience as:

• makes it harder to install krew (first-time/one-time experience)
• makes it harder to install plugins on krew (frequent experience)

Need help from someone to look into this and see if we can do this without needing Administrator privileges.

Some quick search reveals this might be possible:

• https://www.wintellect.com/non-admin-users-can-now-create-symlinks-windows-10/
• https://security.stackexchange.com/questions/10194/why-do-you-have-to-be-an-admin-to-create-a-symlink-in-windows
• https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/
• https://developer.amazon.com/docs/fire-app-builder/configure-windows-symlinks-no-admin-priv.html

/lgtm /approve

We can have this + #375 go into a new release, as both of them address Windows installation issues.

Yeah I guess it's especially fine because we'll remove this code ≥0.5 or maybe earlier.

I'm not aware of anything that can solve this out-of-the box, but I'm open to it. Our logic has some stuff like supporting globs (although doublestar pkg works better for that), checking if a move is allowed (e.g. to: ../../../).

Yeah might as well merge back. that method is basically 3 execs.

mostly lgtm /hold for comments

what if we didn't look for kubectl- prefix? similarly, what if we didn't look for them to be symlinks? we can just ReadDir?

I will give a look if I can simplify anything. Unless possible via stdlib, are we open to a dependency that does it? Also, should I create an issue to track it ?

I recommend looking at the move.go a bit. The naming of the methods makes the hierarchy unclear:

• moveToInstallDir (extractDir → storeDir)
  • moveAllFiles (extractDir → tmp)
    • moveFiles
      • findMoveTargets
        • getDirectMove
          • isMoveAllowed
        • isMoveAllowed
      • renameOrCopy
  • renameOrCopy (tmp → storeDir)

For example, I'm not sure why is "getDirectMove" is a special case. There's already a filepath.Glob code in that method. Could that be already handling single file moves?

Maybe needs fixing, maybe not.

^ Feel free to copy/paste this into a new issue.

Go is surprisingly forgiving when it comes to these things.

I will rename this to copyTree.

SGTM. That would ensure a plugin installed with krew exists (incl krew itself) so it would ensure krew is installed at least :)

It seems like there's no reason to hold off onto the v0.3

• v0.2.1 happened 309 days ago (Oct 24, 2018) and Krew has been working pretty reliably.
• We made a lot of changes since v0.2.1, most of them are cleanup of technical debt. However, these need more testing before more changes are accumulated.
• All P0 and P1 bugs are now closed.

We only have a major backlog item we're deferring to v0.4 release:

• Support for custom index repositories (#23), which will require a long thought process and a detailed design change followed by fundamental core refactoring (which is now easier to do.)

Major notes from this release:

• Post-upgrade, krew will prompt users for running a mandatory migration command before any krew subcommand can be used.
• Krew no longer breaks when an installed plugin deleted/renamed from the upstream index.

/cc @corneliusweig ^ can you please try making a release to exercise this path and see if you have permissions?

/close Ty for the reminder.

there was no need to make a new function IMO. there doesn't seem to be splitting these, esp. since we aren't testing them.

Fixed.

Hmm wait this is weird. I think we need to keep this as os.Rename, so we run into the LinkError below. I'll update, but likely can't test right now.

/assign @corneliusweig

Sounds good. Let’s proceed as is.

@maracaipe @AndrewSav we have a fix at #375!

Can you please try it? You can either build from PR branch or use this file by extracting it and using it to install krew: krew-windows_amd64.exe.zip

Make sure to delete %USERPROFILE%.krew directory first to clean things up after a failed installation (otherwise you may run into another issue #374).

Refer to the kubectl plugin installation option via krew.

• removes global SELF variable
• fixes #181

Signed-off-by: Ahmet Alp Balkan ahmetb@google.com

For some reason basename command is not in PATH apparently when we run the integration tests like

#!/usr/bin/env bats

My suspicion is that either this format, or bats is not inheriting the PATH correctly.

I made a release without going through PR, so the master is now broken.

As subject

The link is not working. :)

Also I don't think we actually need this. It's somewhat an orthogonal concern to be able to specify "multiple" kubeconfig files.

There are blog posts, tools etc to do that. Even I wrote about this https://ahmet.im/blog/mastering-kubeconfig/

• removes global SELF variable
• fixes #181

Signed-off-by: Ahmet Alp Balkan ahmetb@google.com

Refer to the kubectl plugin installation option via krew.

You need to update the link too.

I think we already do cleanup temp dirs.

/lgtm /approve

Also got this feeling like move.go is unnecessarily complex. We could most likely simplify this file using more idiomatic methods from stdlib.

I have not fully tested it.

I had to plug in an SD card on my windows machine to create a true different device (subst command wasn't doing that). And since SD card is FAT, it can't create symlinks.

But this has enabled it to progress installation further than before, and fail at the last step (which is creating the symlink).

It looks like we can generalize copyDir func as "copy" because filepath.Walk works on regular files, too. Making single file move use this renameOrCopy method.

Also fixed a typo.

This should fix #357.

If I try to install krew on windows and fail halfway and receipts/krew.yaml is not written, krew will end up in a situation that requires kubectl krew system receipts-upgrade.

This happens because we look at store/ dir which is not empty. But in this case of a bug (like #357) store/krew/ is actually an empty dir.

https://github.com/kubernetes-sigs/krew/blob/7bd396984863b9379d76b2bc020da78756bd7a54/pkg/receiptsmigration/migration.go#L42-L63

What if we instead looked at entries under bin/ directory?

/area platform/windows /priority P2

Some insights after quick investigation:

1. This happens because we use ioutil.TempDir which happens to point to c:\ and KREW_ROOT is elsewhere.

2. There's definitely a bug in how we handle 'single file' copies vs 'glob' copies wrt cross-device file copying.

3. One can easily use subst K: W:\some\dir\.krew to create a phony letter-drive in user land.

I'll try to spend more time to fix this and verify. Thanks for reporting again.

• add error handling
• gofmt 3 files

Thanks, looks good.

I'm not entirely sure how the error returned error will be used in this case. I suspect we'll start seeing error messages like EOF or interrupt due to these when user hits Ctrl+C or something like that.

At least we're not ignoring it now.

Putting this on hold until we figure out a cleaner design on how we can make this work reproducibly (i.e. without destroying the old value, if exists).

If anyone needs this feature, please add comments.

aside: I feel like we'll soon have to introduce a DeployOptions property-bag here :)

ditto: using bool above eliminates this block

ditto: using bool above solves specifying these values everywhere in the tests.

You can drop * and just make it false-by-default.

Since we don't serialize this object, having the extra field listed doesn't make a difference.

It would be useful to have *bool when/if you're trying to distinguish nil (unset) vs false (zero value).

ditto: using bool above eliminates this block

We can probably still go ahead with this at any rate.

It indeed seems like Brew is automatically copying out these files: https://rubydoc.brew.sh/Metafiles.html I can't easily read ruby code, but my guess is it's only picking these from the repository root, but in our case there's no such concept. For example, in tag tarballs provided by GitHub (imagine bash plugins), the root level dir is technically 1-level nested, like kubectx-v0.7.1/LICENSE.

Thanks for the update.

Let's keep the plugins as is. @aylei if you're still interested in distributing via Krew, we're open to it!

Otherwise we'll wait until the day debug becomes a builtin kubectl command that automatically shadows any exiting plugin.

/close

/hold

Excellent point, I think you're right we should fix this.

To be precise, this is a "distribution" problem and not a problem with "krew" itself, at best, it's a krew-index issue.

• Require that plugin authors also copy over their license(s) in the files field of the manifest. This will require a lot of back and forth with plugin authors until all plugins are updated.

Technically we could do this ourselves easily. It's not a bad idea. Similarly we'd need to make it part of our review procedure for krew-index.

• Add a new mandatory manifest field license which simply states what is the license of the plugin. This is simpler, but maybe not sufficient.

I think a new license field is not going to be the best idea. We actually need the full text. Also, some plugin in the future (such as "private plugins") won't need this field. Making it required will create friction.

I've been trying to recall what Homebrew does, because for many similar formulae (kubectx.rb, kubernetes-cli.rb, fzf.rb, ...) the file doesn't talk about the license.

I am suspecting Homebrew is copying certain files like LICENSE* COPYING* CHANGELOG* out of the repository root as an implicit step, but I cannot find docs on this behavior.

I think fzf is easily findable and makes the text longer, so we should leave it out. I'm similarly thinking all these plugins listing USAGE strings in their caveats/description. Similarly not ideal.

Oh yeah I think I corrected this in the shell, but forgot to update docs. /lgtm /approve

Thanks for catching.

/lgtm /approve

/lgtm /hold cancel

Lets keep this open maybe we can add the tool here as a cmd somehow.

A user new to knative might not know Istio. That's why by default listing KINDs with ApiGroup prefix would be awesome

For example VirtualService.networking.istio.io would be great, because it works like:

kubectl get VirtualService.networking.istio.io

as well, so users won't be confusde.

I realize this tool uses | and L characters, instead you can copy paste from tree command:

.
├── Makefile
├── README.md
├── cmd
│   └── main.go
├── go.mod
├── go.sum
├── hack
│   ├── build-binaries.sh
│   ├── build.sh
│   └── test.sh
│   └── version_test.go

(these characters actually look better in the terminal, i.e. no gaps between pipes etc)

https://github.com/nimakaviani/knative-inspect/blob/0c821a06c2867ef3f792e991f81ba5ae4cbfdfa1/pkg/cmd/core/config.go#L71-L74

I think this part is incorrect, because once I did

export KUBECONFIG=~/.kube/config

it has worked, but this is default for almost all tools, so this should not be necessary. I guess something is missing from config loading rules above.

I'm getting error:

Error: building Kubernetes config: invalid configuration: no configuration has been provided

I can't seem to get past behind this (using a GKE cluster). But it seems like this tool is importing the auth plugins pkg, so I can't tell what's happening.

I also specified --kubeconfig ~/.kube/config, did not work

./kni inspect --kubeconfig ~/.kube/config -s hello

Though cloning the repo and building works.

$ go get github.com/nimakaviani/knative-inspect/cmd
package knative.dev/serving/pkg/tracing/config: cannot find package "knative.dev/serving/pkg/tracing/config" in any of:
	/Users/ahmetb/.homebrew/Cellar/go/1.13.3/libexec/src/knative.dev/serving/pkg/tracing/config (from $GOROOT)
	/Users/ahmetb/go/src/knative.dev/serving/pkg/tracing/config (from $GOPATH)

I suspect it recently broke.

otherwise go get github.com/nimakaviani/knative-inspect/cmd results in building an executable named cmd in ~/go/bin, likely not what anyone wants.