proposal: cmd/go: automatic vendoring in module mode

This proposal overlaps with (and hopefully unifies) several existing issues, linked in the text below.
I'd like to implement it soon, in the 1.13 cycle, so if you have feedback please do respond quickly. 🙂
Problem summary
Users want a durable, local view of their source code that works with existing diff tools and does not require per-user configuration in cloned repositories.

Relying on module proxies does not necessarily satisfy delivery contracts.
Saved module caches do not interoperate well with version-control and code-review tools.
-mod=vendor requires configuration per user (GOFLAGS) or per invocation, and makes it too easy to ship code that produces a different build in vendored mode than in the normal module mode.

Proposal
Under this proposal, the source code for the packages listed in vendor/modules.txt — and the go.mod files for the modules listed in vendor/modules.txt, if any — will be drawn from the vendor directory automatically (#27227).
If a replace directive in the main module specifies a module path, the module source code will be vendored under the path that provides the replacement, not the path being replaced. That preserves the 1:1 correspondence between import paths and filesystem directories, while allowing replacement targets to alias other modules (#26904). If a replace directive specifies a file path, then either that path must be outside the vendor directory or the vendor/modules.txt file must not exist (#29169).
Package patterns such as all and example.com/... will match only the packages that are present in the vendor directory, not unvendored packages from the same module. During the build, if additional packages from the vendored modules are needed in order to satisfy an import, the source for those packages will be fetched (from the module cache, if available) and added to the vendor directory. (Packages from outside the already-vendored modules will not be vendored automatically.)
Any time the go.mod file is written, if a module path found in vendor/modules.txt has a different version than that found in the build list, the already-vendored packages and go.mod file from the previous version will be deleted, and updated versions of those packages will be written in their place (#29058). Transitive imports of those packages will be resolved, and may populate additional packages in other already-vendored modules.
If go get removes a module from the build list entirely, its package source and go.mod file will be removed, but an entry for the module (with version none) will remain in vendor/modules.txt. That way, if a future operation (such as a go get or go build) adds the module to the build list again, it will remain vendored as before.
When go mod tidy is run, it will add or remove packages from the vendor directory so that it continues to contain only the subset of packages found in the transitive import graph. It will also remove go.mod files and entries in vendor/modules.txt for modules that are no longer present in the build list.
To encourage the minimal use of vendor directories, the go mod vendor subcommand will accept an optional list of packages or modules. go mod vendor <module> will update the vendor directory to contain the go.mod file for <module> and source code for its packages that appear in the transitive import graph of the main module. (Note that, since the criterion for inclusion of a package is its existence in the import graph, vendoring in an additional module should not affect the contents of any previously-vendored modules.)
go mod vendor <pattern> for an arbitrary module pattern will add # <pattern> to vendor/modules.txt, and vendor in the go.mod files (and any packages found in the import graph) for modules matching <pattern>, adding individual comments to vendor/modules.txt for those modules.
Note in particular that go mod vendor all will copy in go.mod files for all of the module dependencies in the module graph (and add entries in vendor/modules.txt for those modules). That ensures that after go mod vendor all, go list can produce accurate results without making any further network requests (see also #19234 and #29772).
The go mod vendor subcommand will accept a new flag, -d. go mod vendor -d <pattern> will remove all previously-vendored modules matching <pattern> from the vendor directory (and from vendor/modules.txt), as well as any previously-stored patterns matching those modules (including <pattern> itself, if present).
go mod vendor, without further arguments, is equivalent to go mod vendor all. go mod vendor -d is equivalent to go mod vendor -d all. If go mod vendor -d causes vendor/modules.txt to become empty, it will also remove the entire vendor directory.

Edits

Made module patterns sticky per https://github.com/golang/go/issues/30240#issuecomment-464071411.

(CC @jayconrod @rasky @JeremyLoy @theckman)

To encourage the minimal use of vendor directories, ...

Why are partial vendor folders something we want to encourage? Most use cases listed here and in the linked issues would require all dependencies vendored at all times.
Also, can you clarify if go get or go mod tidy would ever add new modules to the vendor folder, or if running go mod vendor would still be required after every new dependency is added in order to avoid a partial vendor folder?

Why are partial vendor folders something we want to encourage? Most use cases listed here and in the linked issues would require all dependencies vendored at all times.

Some dependencies are more robust than others. For example, you might trust github.com to be generally available, but want to vendor in dependencies that happen to be hosted using bzr or svn so that you don't have to install those tools on every machine that will build your module.

Also, can you clarify if go get or go mod tidy would ever add new modules to the vendor folder, or if running go mod vendor would still be required after every new dependency is added in order to avoid a partial vendor folder?

go get and go mod tidy would not add dependencies to vendor automatically.
We could perhaps make go mod vendor (without arguments) set some flag in modules.txt to indicate that all additional modules should be vendored.

More generally, though, the main goal of automatic vendor updates is to prevent version skew. Copying in newly-added modules does not further that goal, since there are no out-of-date contents in the first place.

I would suspect the most common use case might be vendoring 100% of dependencies? If so, and if vendoring in 1.13 is going to be able to track updates via go get and go mod tidy in some cases, it would seem that likely should be the default behavior for vendoring to do that for all updates (e.g., after a go mod vendor with no args, as you suggested two comments back)?

It definitely makes sense to support partial ones. I just suspect (and might be wrong!) that 90% of users opting into vendoring really mean to vendor everything, and a reasonable chunk of that 90% would be surprised by it behaving otherwise.

In the presence of a reliable proxy, I can't think of any reasonable cases for a partial vendor directory, and lots of possible confusion.
I would personally argue we go in the other direction, as in if you try to build in vendor mode it is not allowed to see anything outside the current module (except the stdlib)

@ianthehat, one use-cases for vendoring, given proxies, is to vendor in private code for which the proxies do not have access.
For example, a contract-based startup might want to vendor in their proprietary utility modules before delivering the code to their customers.

@bcmills Could you comment on the interplay with -mod=readonly, and/or options to disable automatic downloads for people who would prefer to fail if vendor is missing something?

@bcmills you can achieve the same effect by copying to an internal package and rewriting the import paths, which would be more honest, and also allow for local modifications (something else that those kinds of contractors often need to do as well). If you don't want to rewrite the import paths, you could check it in as a sub-module and use a replace directive (you probably have full control of the main go.mods for that kind of work)
Or you could add a directory with the zip and mod files and use it as a file proxy (which is something it might be worth looking into as a better version of vendoring)
I don't think making the normal use much worse for such extreme edge cases would be the wrong choice.

I like removing complexity, flags, and per user (or per project) configuration when using vendored mode. I think that automatic detection of vendor folder (and assume you are in vendored mode) when a vendor folder is present it's a great idea.
I sometimes mix vendored and non-vendored projects, and switching between would be great to be as transparent as possible.
I agree though with the opinion of some of the folks above, IMHO supporting partial vendoring would be confusing and it will add complexity.
For example, in our usecase, we are using non-vendored mode for our main projects, adding a GOPROXY for public libraries, but don't want to cache our private libraries there (for security, and because cache server and source server are on the same local network, it just doesn't add any benefit for us). https://github.com/golang/go/issues/26334 would be enough for this.
Vendored mode, in the other hand, it's great to distribute self-contained/small apps/tools.

@ianthehat

I would personally argue we go in the other direction, as in if you try to build in vendor mode it is not allowed to see anything outside the current module (except the stdlib)

Part of the point of this proposal is to avoid the need for a distinct “vendor mode”. Modules are integrated into the normal go workflow, and if we're serious about supporting vendoring, then I would argue it should be too.

Or you could add a directory with the zip and mod files and use it as a file proxy (which is something it might be worth looking into as a better version of vendoring)

We've considered that, but it really doesn't work well with version control systems: the diffs are incomprehensible and the blobs can end up consuming a lot more space than they ought to (depending on the encoding).

Re partial vendoring: given module proxies, the major use-case for vendoring is for modules that are not available via the public proxies. (Recall that the word “vendor” literally means “one who sells”.)
Module mode substantially reduces the need to duplicate code: you no longer have to copy all of your dependencies into your own repository, and you especially don't need to do that for stable, publicly-available, open-source dependencies. It is important to me that we make it easy to duplicate the minimum amount of code necessary for each use-case: minimal duplication shouldn't be an “extreme edge [case]”, it should be the default mode of operation.
It's not realistic to expect folks to manually apply replace directives for partial vendoring, or to rewrite import paths. It's certainly possible, but it's extremely tedious (see #30241 and #27542): it isn't, and shouldn't be, a default mode of operation. If that were the only alternative to vendoring the full tree, folks wouldn't do it: instead, they'll fall back to duplicating all of the dependencies all over again.
The point of vendoring in module mode is not to provide an alternative to using modules. It is to provide a complementary feature set for the cases that modules cannot address well: namely, the distribution of proprietary code.

That said, let's think about that sticky-pattern problem. I don't buy the “full vendoring as a default” argument, but there is a more general case that really ought to work.
Suppose that I run go mod vendor golang.org/x/.... I should reasonably expect any further dependencies matching golang.org/x/... to be vendored.
If we support that, then we can view go mod vendor without arguments as equivalent to go mod vendor all, and that will provide sticky full-vendoring.

So how about this alternative. For a given module-path pattern,

go mod vendor <pattern>

adds # <pattern> to vendor/modules.txt, and
vendors in the go.mod files (and any packages found in the import graph) for modules matching <pattern>, adding individual comments to vendor/modules.txt for those modules.

go mod vendor -d <pattern> removes from vendor/modules.txt:

<pattern> itself, if present;
all modules matching <pattern>;
and finally, all further patterns that match the removed modules.

@thepudds

Could you comment on the interplay with -mod=readonly, and/or options to disable automatic downloads for people who would prefer to fail if vendor is missing something?

Under this proposal, -mod=readonly would continue to disable updates to the go.mod file, but any imports already listed in vendor/modules.txt that are found during a go build would be copied into the vendor directory.
-mod=vendor would continue to exist, and would mean “do not resolve imports that are not found in either GOROOT or vendor”. However, since we would now vendor in go.mod files as well, go -mod=vendor would produce more accurate results from subcommands like list, mod why, and mod graph that examine the structure of the module graph.

So how about this alternative. For a given module pattern,

go mod vendor <pattern>

adds # <pattern> to vendor/modules.txt, and
vendors in the go.mod files (and any packages found in the import graph) for modules matching <pattern>, adding individual comments to vendor/modules.txt for those modules.

go mod vendor -d <pattern> removes from vendor/modules.txt:

<pattern> itself, if present;
all modules matching <pattern>;
and finally, all further patterns that match the removed modules.
And then go mod vendor is defined to be equivalent to go mod vendor all.

I think this works very well for me, thanks. I couldn't reason through all the cases you listed in your original post (I'll try to go through them over the weekend), but surely this command line API looks good and the sticky mode is really good.
Is there really a need to introduce a third metadata file (vendor/modules.txt), after go.mod and go.sum? Did you think of adding a vendor command to go.mod?

@bcmills Is the thinking that this would also land in 1.13 along with the currently proposed new behavior:
#27348 "cmd/go: allow verifying vendored code"
If so, under the latest proposal, is this an example of what a module author could do if they want to fail if vendor is incomplete:

in the author's own builds or in their CI, they could run with -mod=vendor to fail if vendor is incomplete
for consumers, the author does not have control over what consumers do (and relying on a README stating "please set -mod=vendor" is not a desired solution). However, the author running go mod vendor (no args) should provide a complete vendor directory on an on-going basis based on the proposed tracking behavior, and in addition the author could run go mod verify -vendor (or go mod vendor -verify or whatever incantation) to verify that vendor is both correct and complete? And if go mod verify -vendor is successful (say, prior to releasing a new version of a module), the author would have confidence that a consumer would never automatically download new code to populate vendor (even if the consumer is not running with -mod=vendor or mod=readonly)?

Is there really a need to introduce a third metadata file (vendor/modules.txt), after go.mod and go.sum? Did you think of adding a vendor command to go.mod?

I hadn't really considered it: I think @rsc added vendor/modules.txt in 1.11, and given that it's already there I figured we could keep using it.
I suppose that we could record the patterns in go.mod instead, but I have a mild aesthetic preference for keeping them in modules.txt. I'm certainly open to arguments to the contrary, though. 🙂

Updated the proposal comment to incorporate sticky patterns (https://github.com/golang/go/issues/30240#issuecomment-464071411).

We've considered that, but it really doesn't work well with version control systems: the diffs are incomprehensible and the blobs can end up consuming a lot more space than they ought to (depending on the encoding).

If your use case is because the code cannot live in a public proxy, why do you care about the diff, you would not see the diff if it was in the public proxy. It's also trivial to fix, use a non compressed text archive. This also fixes the space issue.

Part of the point of this proposal is to avoid the need for a distinct “vendor mode”. Modules are integrated into the normal go workflow, and if we're serious about supporting vendoring, then I would argue that vendoring should be integrated too.

I think we ought to start by enumerating the actual problems we are hoping to solve with vendoring, and checking it is the right solution to those problems. Vendoring comes with a lot of serious problems, it needs to be worth the cost.

If your use case is because the code cannot live in a public proxy, why do you care about the diff, you would not see the diff if it was in the public proxy.

For a start, if you're vendoring the code because it is proprietary, you want to be sure that you are shipping only what was actually promised to the customer.

It's also trivial to fix, use a non compressed text archive.

That is essentially what the vendor directory is: it just happens to be text archive format that can also be consumed by pre-module versions of the go command.

I think we ought to start by enumerating the actual problems we are hoping to solve with vendoring, and checking it is the right solution to those problems.

https://github.com/golang/go/wiki/ExperienceReports#vendoring is a good place to start.
Specific use-cases I'm aware of are:

Shipping proprietary dependencies to customers under contract.
Providing reproducible builds for Go releases that predate module support.
Unpacking source code for temporary auditing or ephemeral debugging.

One use-case is sometimes mentioned, but arguably better served by a module proxy (or, equivalently, a saved module cache):

Providing hermetic builds for CI systems.

The latter use-case is not a significant factor in this proposal, although it may be address by this proposal incidentally.

Shipping proprietary dependencies to customers under contract.
This is the interesting one, and I still think vendoring is totally the wrong choice for this.
We redestribute modules using a proxy, this is just a custom proxy, so lets do it that way. Vendoring is a horribly confusing to the user way to distribute a module.

Providing reproducible builds for Go releases that predate module support.
I don't think this is an interesting case, you are talking about adding features to the go command, to use them you inherently must have a go command that supports modules, and that's our story for reproducible builds. I don't think it is unreasonable to say if you want reproducible builds you should upgrade to modules.

Unpacking source code for temporary auditing (such as using grep -r) or ephemeral debugging (such as inserting println statements).
This is exactly what the replace directive is supposed to be for, if it does not work well, lets fix it, not suggest vendoring as an alternative.

Suppose that I run go mod vendor golang.org/x/.... I should reasonably expect any further dependencies matching golang.org/x/... to be vendored.

@bcmills To make sure I understand correctly, that would include any future packages that you obtain via go get ...? If so I don't agree that you should expect it, because you're requiring people to need to manually do it in the first place. We're training them to not expect it.

Another vendoring use case:

Providing reproducible builds for Go software without the need for a highly available proxy, or automation to synchronize Module caches between CI systems and developer workstations.

If your use case is because the code cannot live in a public proxy, why do you care about the diff, you would not see the diff if it was in the public proxy.

For a start, if you're vendoring the code because it is proprietary, you want to be sure that you are shipping only what was actually promised to the customer.

Which is true for any module you ship, and you would have more confidence in this if you are using modules as the distribution mechanism because you know the version and checksum in the mod file are correct, which is much better than trying to diff the source.

It's also trivial to fix, use a non compressed text archive.

That is essentially what the vendor directory is: it just happens to be text archive format that can also be consumed by pre-module versions of the go command.

Except it is not, the vendor directory is real code that you can modify, have no idea if it has been modified, and breaks assumptions about import paths. It causes many problems for tools, and much confusion for users.
A local module proxy however has none of these issues. It will not appear as code in your editor, and unlike vendor directories it would be totally safe to use the module proxy in all your dependancies as an alternative source of modules. You can also still control the version across multiple dependancies unlike vendoring.

@theckman, note that a filesystem tree is a valid module proxy.
That means that “without the need for a highly available proxy” is equivalent to “without the need for a reliable filesystem”, and if your CI system does not have a reliable filesystem you're probably not going to have a good time with go build anyway.
(But that's mostly irrelevant, because we plan to have highly available public proxies anyway: see https://blog.golang.org/modules2019.)

To make sure I understand correctly, that would include any future packages that you obtain via go get ...?

Yes, or any future packages that you obtain by adding an import of a package and letting go build resolve that import.
Basically, under this proposal (with “sticky vendoring”), go mod vendor <pattern> tells the go command to always keep the vendor directory up-to-date for everything matching <pattern>.

@ianthehat

you are talking about adding features to the go command, to use them you inherently must have a go command that supports modules, and that's our story for reproducible builds.

I'm talking about adding features to manage the vendor directory. Previous versions of the go command back to 1.6 can consume the vendor directory, and (unless I have made a serious mistake, which is possible) the directory tree created under this proposal remains compatible with them.

That means that “without the need for a highly available proxy” is equivalent to “without the need for a reliable filesystem”, and if your CI system does not have a reliable filesystem you're probably not going to have a good time with go build anyway.

@bcmills if I build inside of containers, I will intentionally not have a reliable filesystem within CI. It'll be completely blown away after the resulting binary is yanked out of the container.

(But that's mostly irrelevant, because we plan to have highly available public proxies anyway: see https://blog.golang.org/modules2019.)

Google, much like NPM, has not been 100% immune to service-interrupting issues. It's the nature of the business, and so I don't feel your comment is a valid counter-point. People will deploy bad code or configuration, systems will fail, etc.

Unpacking source code for temporary auditing (such as using grep -r) or ephemeral debugging (such as inserting println statements).

This is exactly what the replace directive is supposed to be for, if it does not work well, lets fix it, not suggest vendoring as an alternative.

If you like, you can think of vendor/modules.txt as defining a set of replace directives, along with a set of rules to update those replace directives based on future changes to the build list.
That's actually where I started this design: with the question, “what would it look like if we unified vendoring and replacements?”
The interesting part is the automatic-update step, since we want the auditable form of the code to stay in sync with the actual modules in use. vendor is what you get if you produce the source code from the modules; replace is what you get if you produce the modules from the source code.

@theckman

Google, much like NPM, has not been 100% immune to service-interrupting issues. It's the nature of the business, and so I don't feel your comment is a valid counter-point. People will deploy bad code or configuration, systems will fail, etc.

I would be very surprised if Google were the only organization maintaining a public module proxy. If Google's proxy goes down, you can set GOPROXY to point to someplace else and keep on working.

@ianthehat

the vendor directory is real code that you can modify, have no idea if it has been modified

That's #27348, and I expect we'll address it by 1.14 (if not yet in 1.13).

@bcmills Now introduces further complexity and additional trust issues around that proxy and whether they are safe for use, further convincing me that my call-out for use case is valid. If the main official proxy goes down, I'm confident the overwhelming majority of users are not going to spend the development cycles to identify a trusted alternative proxy, and to then update all of their CI configurations to use it.

@theckman, the issues of proxy trust are certainly valid, and they will be addressed in-depth in other proposals for Go 1.13. Stay tuned!
However, those details are a bit off-topic for this proposal.

At any rate: while I don't agree that reproducible builds are a compelling use-case for vendoring, the current proposal supports that use-case anyway.
We can (and, I hope, will) come to agreement on a design even if our underlying reasons for it differ.

Shipping proprietary dependencies to customers under contract.

This is the interesting one, and I still think vendoring is totally the wrong choice for this.
We redestribute modules using a proxy, this is just a custom proxy, so lets do it that way. Vendoring is a horribly confusing to the user way to distribute a module.

I think we have different users. With vendoring support, my customers don't even need to be aware what vendoring is. I provide a git repository, they clone it and run "go build"; everything works, and everything is self-contained (shipping all the dependencies in source code format is part of many of my contracts, and vendoring allows me to honor this clause very easily and effortlessly).
You seem to suggest that your customers/users are happy with setting up "custom proxies" (whatever that means) in addition to cloning the project for the purpose of building it, possibly using additional documentation that you have provided them with. I'm happy it works for you, and I can assure you that you will not find me passionately arguing against custom proxies in GitHub issues just because I don't use them.
If you don't have a use case for vendoring, please rest assured that there are many people who do, and there have been multiple discussions going on on GitHub issues and directly with Google to try to have proper vendoring support with modules as well. If you feel so strongly, please open a proposal to remove vendoring from the Go toolchain, but I think it's better not to hijack this issue by arguing on the actual merits of vendoring.

@theckman @bcmills As far as I can see, I think you might be agreeing with each other that you both seem to view that a filesystem-based module cache that is checked into VCS is not a valid substitute for a traditional vendor directory.
To evaluate whether or not some proposal is a valid substitute for a traditional vendor directory, it is valuable to spell out use cases serviced by a traditional vendor directory and compare against future proposed behavior, and you can describe and compare behaviors of traditional vendoring, etc.
But at least for me, if you wanted to try to put it in a single sentence, the most important part of evaluating whether or not a future solution is a valid substitute for a traditional vendor directory might be:
Allow tracking third-party code in VCS in a similar to manner to how you track your own code.
(And there can be different reasons people desire this: VCS is the ground truth for your source code and should be the ground truth for other code you use or ship even if someone else wrote it; greater trust in your VCS than any other external system;  VCS is more likely to survive over longer timescales or migrate forward in the face of change; the desire to use standard VCS tools (diff, tagging, blame, bisect, etc.) on third party code in a similar manner to how do; building when disconnected from the public Internet; internal policy; compliance; auditing; etc).
My personal view is a file-based proxy or module cache checked into VCS does not meet that threshold. One example is a file-based proxy I think has N copies of different versions of a dependency under file directories like v1.2.3, v1.2.4, etc., which is not how you track your own code in VCS. That then has different implications for how you interact with that dependency code.
But I would also suspect different people would boil it down to a different single sentence, and perhaps the topic is too nuanced to try to capture in a single sentence.

I think we have different users. With vendoring support, my customers don't even need to be aware what vendoring is. I provide a git repository, they clone it and run "go build"; everything works, and everything is self-contained (shipping all the dependencies in source code format is part of many of my contracts, and vendoring allows me to honor this clause very easily and effortlessly).
You seem to suggest that your customers/users are happy with setting up "custom proxies" (whatever that means) in addition to cloning the project for the purpose of building it, possibly using additional documentation that you have provided them with. I'm happy it works for you, and I can assure you that you will not find me passionately arguing against custom proxies in GitHub issues just because I don't use them.

Sorrry, I was not clear.
I am suggesting that checking in a proxy directory that the go command knows how to automatically use would be a superior solution to checking in a vendor directory if this was the only concern. It meets all the requirements for a stand alone build in a way that unifies with modules cleanly, and has none of the drawbacks of a vendor directory.

@bcmills I agree with your problem summary and proposed solution. This is a great proposal. I went back and forth on the module pattern. I think it is more then athletics to put the patterns in modules.txt, as it pertains only to the act of vendoring, and not to module or go versions. So I agree with your proposal on that as well fully.
Thank you. This will make modules even easier to use for myself and my team.

This proposal has an interesting interaction with #27852. If we start storing go.mod files in vendor directories, then nothing in the vendor directory will be included in the module cache.
That's probably fine, because building within the module cache doesn't work in general anyway (modules may have replace directives pointing to files outside of the module), but — that being the case — we could trim out a lot of code bloat in the module cache by explicitly excluding the vendor directories associated with cached modules.

The more I think about it, the more I think we should exclude the vendor directory from the module cache entirely. It's pretty much guaranteed to be redundant. Will edit this proposal accordingly.

This all makes sense for "package main" type modules, but what happens if you run go mod vendor under a library package with this proposal?

@driusan, why would it need to be any different for modules containing libraries?
(Note that in module mode, we only ever use the vendor directory of the main module. Packages vendored by dependencies are not searched and not relevant to the build: that way, the main module has complete control over which dependency versions are in use, and there is only one non-test copy of the source code in use for each package import path.)

@bcmills Your note is why I think it should be different (and should probably result in an error).. if it behaves the same way regardless of whether it's a main module or a library module, it would result in spurious vendor directories that are never used (under any circumstances) when run under a library package, which is probably not what the user intended.

The vendor directories would still be used when working within that library module itself, and when compiling the program in GOPATH mode (for example, using an older version of the Go toolchain).
The use-cases for vendoring in library modules are a bit less compelling than for modules that include main packages, but as far as I can tell that difference mostly only affects the decision about whether to use a vendor directory at all — not what it should do if present.
(Note that the inclusion of go.mod files under this proposal will tend to exclude the vast majority of vendor directory contents anyway.)

@bcmills
My experience report:
I vendor all the dependencies, I do not modify the vendor folder (I do not edit or patch sources there). My build is offline and fails if I have a missing dependency. No magic, I'm happy.
My expectations from new tools provided by Go itself:

Keep the old behavior of the vendor folder (which we had for years, literally);
Work outside of GOPATH (which simplifies development).

Please provide a simple and reliable solution which satisfies the community's expectations.
I've read both big threads and I see that there are basically two use cases:

Vendor all the dependencies.
Vendor none.

And one potential use case:

Vendor some.

I haven't seen experience reports with this one (maybe I missed one, these threads are super big). But this potential case smells like nobody likes complexity like setting up a proxy with access to private repositories.
Thanks!

@selslack, thanks for the report, but it would help even more if you could share the why of your current workflow instead of the what. (In particular: why, if at all, would you prefer to vendor packages rather than modules? Why, if at all, would you prefer to vendor source files rather than zipfiles?)
We know how things work today, but we also know that for at least some use-cases there will be better alternatives in module mode. I want to optimize the vendor functionality for the subset of use-cases that don't have a better alternative.

@bcmills sorry for responding a month late, and thank you for writing this proposal!
So lets walk through a scenario, and please correct me if I get anything wrong:

I have a preexisting  go project.
I have a need to add a dependency to a project, and I wish to vendor it
I run go mod vendor _pkgname_, which downloads the source code into the vendor directory
I update my project to use the new dependency
go build _mainpkgname_ works

This is a slightly different scenario than what I was originally envisioning, which was making go get vendor aware.
It's not bad, still just one command: go mod vendor _pkgname_.
Because partial vendor support is something mentioned above, I think this is an adequate compromise. It does feel a bit odd though. It definitely doesn't feel as nice as go get effortlessly switching between go path and module mode.

Is there a specification documented for vendor/modules.txt?
I want to update my own vendor tools because we seem to be going round in circles here and making vendor'ing way more complicated than it needs to be.

Hi @JeremyLoy

This is a slightly different scenario than what I was originally envisioning, which was making go get vendor aware .
It's not bad, still just one command: go mod vendor pkgname.

As far as I understand the current proposal, the common case is that you would do a one-time operation of go mod vendor(which is a synonym for go mod vendor all).
Once you've done that, you've signaled your desire to use vendoring, and at that point the vendor directory will automatically track any subsequent go get<EMAIL_ADDRESS>and go get bar and also even if you add a new import path to your code for a previously unused module and do something like go build. In other words, once you do the one-time operation of go mod vendor, you would not need to separately do go mod vendor foo and go mod vendor bar. Was that part of your concern? Sorry if I have misunderstood the concern.

@thepudds that may in fact be the case. My initial impression from reading the proposal was as you described, but all of the follow up discussion in this thread regarding support for partial vendoring is where I am confused.
I personally don't see a need to support partial vendoring, at least for initial release. It just complicates the issue. Simply making go get vendor aware for this first pass doesn't exclude partial vendoring from a future release.

@bcmills what happens if I have a Module I depend on named all defined in my go.mod, and I only want to vendor that? How do I only vendor all and not github.com/theckman/example too?

@JeremyLoy

@thepudds that may in fact be the case. My initial impression from reading the proposal was as you described, but all of the follow up discussion in this thread regarding support for partial vendoring is where I am confused.

The history of the conversation here is slightly confusing. The initial proposal was a bit different, so the first 18 or so comments above were reacting to that initial proposal. The proposal was then updated at the time of https://github.com/golang/go/issues/30240#issuecomment-464071411 in a way that largely addressed many of the initial concerns in those first 18 or so comments. I think the change in the proposal at that time also addressed what I think was the primary concern you were expressing in https://github.com/golang/go/issues/30240#issuecomment-474541877. I understand that you also expressed concern that you might not need partial vendoring, but I think what might have been your primary concern around the common case of go mod vendor automatically tracking future go get foo and similar commands is part of the current proposal (without the need to also do go mod vendor foo).
In other words, if you read the proposal as it stands now in the first comment https://github.com/golang/go/issues/30240#issue-410509265 and mostly like what it currently describes, then that is a good sign. As far as I am aware, the proposal as it stands now in the first comment is a complete description of the current proposal.

@nomad-software, there is no current formal specification for modules.txt, and I don't intend to provide one: as demonstrated in this proposal, the format may be subject to change (although it should remain broadly compatible in the face of any changes).
The programmatic entry points for tools to interact with vendor in module mode are go list and go mod vendor. Anything beyond that should follow the proposal process.

@theckman

what happens if I have a Module I depend on named all defined in my go.mod, and I only want to vendor that?

Module paths without a dot in the first component are in general reserved for the standard library: it seems exceedingly unlikely that there will ever be a module with a literal module path of all that you can go get or go mod vendor.

That ensures that after go mod vendor all, go list can produce accurate results without making any further network requests (see also #19234 and #29772).

It occurs to me that this might not actually remove the need for network access — at least not without significant changes to module-mode loading. It is possible that some dependency found in the module graph (go list -m) is only reached through an earlier-than-selected version of some other dependency, and since the vendor directory would contain only the most recent version of the go.mod file, that part of the module graph could be missed if we only consult the vendor directory.
I suspect that go list without -m would be fine, but go list -m in particular might still need network access.

@bcmills would it be reasonable to populate the older go.mod files as well in the vendor directory during a go mod vendor under this proposal?
This might not be the proper analogy, but in other words, would it be reasonable to place in vendor the go.mod files you would end up with if you manually did something like GOPATH=$(mktemp -d) go mod download in 1.12 today (or similar if that is not correct in 1.12)?

@thepudds We would need to put the go.mod files at some path that contains the complete (presumably canonical) version as a path component: otherwise, they might overlap with the go.mod files vendored for other versions of the same module. The module cache, not the vendor directory, is where we put per-version files today, and adding a similar facility to the vendor directory would be a significant overlap.
I suppose that goes to @ianthehat's broader point about the overlap between the module cache and the vendor directory.

We would need to put the go.mod files at some path that contains the complete (presumably canonical) version as a path component

Yes, agreed.

I suppose that goes to @ianthehat's broader point about the overlap between the module cache and the vendor directory.

The glass-half-full way to look at that might be that the logic to track go.mod files in a version-aware manner would not need to be invented from scratch for vendor  ;-)

Or you could add a directory with the zip and mod files and use it as a file proxy
(which is something it might be worth looking into as a better version of vendoring)

That's issue #31302

We've considered that, but it really doesn't work well with version control systems: the diffs are incomprehensible and the blobs can end up consuming a lot more space than they ought to (depending on the encoding).

That's only the case if you want to keep everything in a single VCS repository. In a large organization, where curating external code is done by many people/teams, you want to split the vendoring in separate repositories, that produce read-only modules, that are then consumed by all the organization projects.
The only reason all this stuff is in single huge vendor directories right now is that there was no robust way to share curating results in Go. Now we have one, that's modules + goproxy (#31304)

what happens if I have a Module I depend on named all defined in my go.mod, and I only want to vendor that?

Module paths without a dot in the first component are in general reserved for the standard library: it seems exceedingly unlikely that there will ever be a module with a literal module path of all that you can go get or go mod vendor.

IIRC modfile.Parse will error out if there is not at least one dot in the module name (for the branch exposed in github.com/rogpeppe/go-internal/)

@bcmills an additional experience report for me, but it's easier to quote @selslack

I vendor all the dependencies, I do not modify the vendor folder (I do not edit or patch sources there). My build is offline and fails if I have a missing dependency. No magic, I'm happy.

This is exactly it for me, and why so far I've avoided using go modules and kept my dep+vendor workflow.
Why? The target environment for a project has no internet access, and it is a requirement for us to be able to build it in that environment. Vendoring has made accomplishing this incredibly simple and I never have to worry about whether my project will build correctly.
Sure, there are other ways of solving this problem as mentioned above (caches, etc), but vendoring is so incredibly easy to use/understand that I don't see why I would bother.
A side effect of committing all my dependencies to a vendor git repo is that it makes it really easy to audit any incoming changes to dependencies and watch for unexpected changes. I admit a filesystem cache as mentioned above could accomplish this same goal.

I'm running out of time in the 1.13 cycle. I still want to make this happen, but unfortunately it's going to slip to 1.14.

@bcmills: What do you think about an alternative solution, where you'd flip a switch in go.mod to turn on "auto vendor" mode. When a module is in "auto vendor" mode, the following things would happen:

All changes to the dependencies (go get ...) would automatically be vendored to /vendor/...
All respective commands (go build/go run/go test) would always run with -mod=vendor

I feel like this would be the most sane solution for me, and pretty much comparable to dep or glide workflow which worked a treat for us for a long time.

@bcmills I want to add a recent story of how the proper vendoring saved us a lots of time: https://success.docker.com/article/docker-hub-user-notification.
As a part of security review after receiving this notification -- we performed an audit of all the dependencies in Java, NPM, etc.
Auditing our Go code took exactly 0 seconds, because we have all the dependencies committed and we don't go online during build process at all.

@bcmills: What do you think about an alternative solution, where you'd flip a switch in go.mod to turn on "auto vendor" mode. When a module is in "auto vendor" mode, the following things would happen:

All changes to the dependencies (go get ...) would automatically be vendored to /vendor/...
All respective commands (go build/go run/go test) would always run with -mod=vendor

I feel like this would be the most sane solution for me, and pretty much comparable to dep or glide workflow which worked a treat for us for a long time.
Edit:
To be more specific about my comment above: I'd prefer it, if having a /vendor directory would be sufficient enough to signal the Go tools that I want 100% of my dependencies vendored all the time and that all tools should run in -mod=vendor mode. But I understand, that this approach is not really something the Go team considers, so maybe having a setting in go.mod is.

I agree.
I think we should consider actually removing -mod=vendor flag, and moving it to a per-project configuration of some sort.
With that flag as it currently is, we're not going to solve the problem that is outlined as a part of this issue's original posting: configuration per user via GOFLAGS. It would still be required for some projects as long as -mod=vendor has the meaning that is actually depending on what are you trying to do in a project (current task) rather than on what project you're doing it (global task).
To be more specific, I'd still want to have -mod=vendor enabled all the time to force go to never try to load anything from the network without explicit go mod vendor invocation in some of the projects I'm working on.

Following a good discussion at GopherCon with @ChrisHines, we concluded that a key reason for needing vendor today (in his situation at least) is touched on by the second bullet point in @bcmills' description:

Saved module caches do not interoperate well with version-control and code-review tools.

Put another way: vendor is used because there isn't a better alternative to reviewing dependency changes alongside (and as part of the same process as) changes to one's own code.
We further concluded that all other aspects of his requirements (including reproducible builds, self-contained CI runs etc) could be satisfied by alternative means, not least, for example, an approach similar to https://github.com/golang/go/issues/27618. None of these alternatives are currently as polished/easy as the vendor workflow, but they would do the job (and could become more polished).
Back to the point on reviewing dependency changes. This point is obviously critical. Not only for those people who prefer the vendor flow because they can easily solve this problem as part of their existing work flow, but for everyone who uses Go modules. We can't, today, point to a tool that helps us achieve this.
That said, to avoid the problems of only having parts of modules "vendored", I think this points towards a solution where entire modules are "vendored" with a directory structure similar (identical?) to that found under $GOPATH/pkg/mod. Whether it's all modules or some I defer to others. This keeps modules intact (important in keeping the solution simple for tools etc) and retains the current benefits of being able to review dependency changes alongside one's own changes. Whether this is achieved by implicit replace directives or any other means, I again defer.
Apologies if I'm late to the party on all of this: I just wanted to stress/highlight that this point on code review has a life well beyond this issue that is of much wider interest.

On that back of my last comment I've just raised https://github.com/golang/go/issues/33466

I think this points towards a solution where entire modules are "vendored" with a directory structure similar (identical?) to that found under $GOPATH/pkg/mod

Just to slightly row back on this point: whether we need the entire module to be "vendored" is actually something I defer to Bryan (and Ian) on. If cmd/go can make things work in a partial way then I don't actually see a reason to "vendor" the entire module (indeed, given the code review point there is good reason not to). Because go/packages et al will just "work" because cmd/go "works"
I previously wrote "entire module" because I read (perhaps incorrectly) that this had become necessary. But Bryan/Ian are the authorities on that point, so restating that point for clarity.

It would great to vendor a single module. We have a library that has a directory with .yaml files(openAPI types common for multiple services). These files are used by other projects, they include these files in their own API specifications. Now we vendor all dependencies, and can invoke a command from makefile that generates go code from service api spec and types from lib (can reference them ./vendor/someRepo/file.yaml )


update Tuple.value according to the url annotation

Tuple.value should handle the url annotation defined in informatics-isi-edu/ermrest#93.
If the annotation is defined, the value should be formatted accordingly. We also need a method that the app can check whether to treat the string as an html or not.

@chiragsanghvi you mentioned a couple of template plugin. Can you list them here?

Mustache is a lightweight templating library.
A heavy version with more set of features is Handlebars

@karlcz @robes can you check these templating libraries? For now, I will assume that we will continue to use the same template that we have been using.

@hongsudt
Yes, just to ennumerate…the 4 cases are

Normal Link : [Chaise](https://dev.isrd.isi.edu/chaise/search)

Normal Image: ![Image](http://assets.barcroftmedia.com.s3-website-eu-west-1.amazonaws.com/assets/images/recent-images-11.jpg)

Image with size: ![ImageWithSize](http://assets.barcroftmedia.com.s3-website-eu-west-1.amazonaws.com/assets/images/recent-images-11.jpg =200x150)

Download Link: Download

Copy following javascript code here to check for their appearance.
var md = require('markdown-it')({ html: true }).use(require('markdown-it-imsize'));

console.log(md.renderInline("[Chaise](https://dev.isrd.isi.edu/chaise/search)"));

console.log(md.renderInline("![Image](http://assets.barcroftmedia.com.s3-website-eu-west-1.amazonaws.com/assets/images/recent-images-11.jpg)"));

console.log(md.renderInline("![ImageWithSize](http://assets.barcroftmedia.com.s3-website-eu-west-1.amazonaws.com/assets/images/recent-images-11.jpg =200x150)"));

console.log(md.renderInline("Download"))

@hongsudt @karlcz  Will this syntax work ?
# Iframe with height and width
::: iframe [Chaise](https://dev.isrd.isi.edu/chaise/search){width=800 height=300} \n:::

# Link
[ChaiseLink](https://dev.isrd.isi.edu/chaise/search)

# Download Link
[Jquery Download](https://code.jquery.com/jquery-3.1.0.js){download .btn .btn-primary}

# Image
![ImageWithSize](http://assets.barcroftmedia.com.s3-website-eu-west-1.amazonaws.com/assets/images/recent-images-11.jpg)

# Image with size
![ImageWithSize](http://assets.barcroftmedia.com.s3-website-eu-west-1.amazonaws.com/assets/images/recent-images-11.jpg){width=800 height=300}

You can see the output here

I like it.. The syntax is consistent..

Yeah this seems like good notation but the output HTML needs a little work...

Chaise

The quotes around the div.style and div.class should be " not '. And the quotes are missing around iframe.src, widht, and height...

Syntax looks good 👍

@karlcz Yes, I will make  the changes in formatting.

Can we make it so that I can leave any number of spaces after ::: e.g. :::  iframe?

@chiragsanghvi The link above no longer points to the markdown usecases, so I can't easily test this.
Does iframe support any number of white space prior to that keyword?

Yes, it supports any number of whitespaces after the iframe keyword, but not before it.
# This will work
:::iframe     [cap](http://www.example.com) \n:::

# This won't work
     :::iframe     [cap](http://www.example.com) \n:::

It is a lot of work to make it support any number of white space before
iframe?
On Wed, Aug 24, 2016 at 3:04 PM, Chirag Sanghvi<EMAIL_ADDRESS>wrote:

Yes, it supports any number of whitespaces after the iframe keyword, but
not before it.
This will work
:::iframe     cap \n:::
This won't work
 :::iframe     [cap](http://www.example.com) \n:::

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/informatics-isi-edu/ermrestjs/issues/140#issuecomment-242222960,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZUDAjZLRt0R6OF-lRhJqCuAjc1ZyiRks5qjL_2gaJpZM4JeJsi
.[image: Web Bug from
https://github.com/notifications/beacon/AAZUDEepBtqi3LkvSV3yloBjk4lvTJ2lks5qjL_2gaJpZM4JeJsi.gif]
{"api_version":"1.0","publisher":{"api_key":"
05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":
{"external_key":"github/informatics-isi-edu/ermrestjs"
,"title":"informatics-isi-edu/ermrestjs","subtitle":"GitHub
repository","main_image_url":"https://cloud.githubusercontent.com/assets/
143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","
avatar_image_url":"https://cloud.githubusercontent.com/
assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png
","action":{"name":"Open in GitHub","url":"https://github.
com/informatics-isi-edu/ermrestjs"}},"updates":{"
snippets":[{"icon":"PERSON","message":"@chiragsanghvi in #140: Yes, it
supports any number of whitespaces after the iframe keyword, but not before
it.\r\n\r\nsh\r\n# This will work\r\n:::iframe [cap]( http://www.example.com) \\n:::\r\n\r\n\r\nsh\r\n# This won't work\r\n :::iframe [cap](http://www.example.com) \\n:::\r\n"}],"action":{"name":"View Issue","url":"https://github.
com/informatics-isi-edu/ermrestjs/issues/140#issuecomment-242222960"}}}

There's just a change needed in the regexp. But do we really need to allow that. Its actually wrong syntax. Markdown will never allow to have a space between the caption and the href for the anchor syntax [caption] (http://www.google.com)

I just tested it on github and I was able to put space between [] and () e.g. [ test ]  ( http://dev.isrd.isi.edu )

The Commonmark spec says that the
"link text" i.e. [My anchor] is supposed to be followed immediately by
the open paren.  I don't see why we want to code in support for sloppy
markdown and encourage our users to learn bad markdown habits...
Similarly, it says that a fenced code block can have at most three
spaces before the code fence (the opening three characters ``` or
~~~).  I think our custom containers are based on this and probably
need to follow the same rules before their opening :::?

For clarification, I meant supporting white spaces between ::: and the word iframe.

Spaces between the ::: and iframe should be allowed if these containers behave like a code fence.  The commonmark spec says that space around the "info string" is allowed and stripped.

Ok, we can do that. They do actually act like code fence but our specification needs it to be single line. So adding the space handling just makes it more error friendly, but adds no purpose or feature.


[top/dv] Add inject_scramble_seed test

fixes #15035
This test begins in production state and burns scrambling keys into the OTP.  It then reboots to bootstrap and flashes in the same image with scramble turned on.
The image is then run, proving that we are able to load a scrambling key.

Signed-off-by: Timothy Chen<EMAIL_ADDRESS>

@moidx @alphan please have a look.
There are two things left:

how can we speed up the read verify (is it okay to use a define for now?)
how should we actually handle the scramble setup.

@moidx @alphan please have a look. There are two things left:

how can we speed up the read verify (is it okay to use a define for now?)
how should we actually handle the scramble setup.

i could also just keep the read verification for now... it's not critical that we have a way to remove it.  Maybe i can do that to make everyone's lives easier.


error in demo 75

fixed with https://github.com/abap2UI5/abap2UI5-samples/commit/730f8107eb0a7b163b28849f1222759c0b990cfa


v0.8.8_01: ‘x’ symbol on tool tip is truncated. #937 & #964 update & #992 & #1024

merged manually due to conflict


Update _start_game and _end_game

(https://github.com/Kush-Gold-Rush/MineShaft/issues/9)
Find and start the game
And end the game

Sure you did try to run this function on your computer? I will try to run it tonight then.

I have correct to not use global variables, and success to run

Docstring not good, I will ask Sharon to help on that. And can you check if the subprocess implementation can still apply the try/catch in __init__ for the error if game not installed?


Fix TS compilation error on tsc 4.5.4

Fixes  for error when running bazel run //test-suite:server-ts -
../../djinni/vendor/third-party/proto/ts/test.ts:3:23 - error TS2497: This module can only be referenced with ECMAScript imports/exports by turning on the 'esModuleInterop' flag and referencing its default export.

3 import * as Long from "long";
                        ~~~~~~

../../djinni/vendor/third-party/proto/ts/test2.ts:3:23 - error TS2497: This module can only be referenced with ECMAScript imports/exports by turning on the 'esModuleInterop' flag and referencing its default export.

3 import * as Long from "long";

Thank you!


cleanup warnings for _set_chan_type

Before:

test_icarename.py:8: RuntimeWarning: The unit for channel ICA 002 has changed from NA to V.

  raw.set_channel_types(mapping);

The unit for channel ICA 002 has changed from NA to V.

test_icarename.py:8: RuntimeWarning: The unit for channel ICA 005 has changed from NA to V.

  raw.set_channel_types(mapping);

The unit for channel ICA 005 has changed from NA to V.

test_icarename.py:8: RuntimeWarning: The unit for channel ICA 001 has changed from NA to V.

  raw.set_channel_types(mapping);

The unit for channel ICA 001 has changed from NA to V.

test_icarename.py:8: RuntimeWarning: The unit for channel ICA 003 has changed from NA to V.

  raw.set_channel_types(mapping);

The unit for channel ICA 003 has changed from NA to V.

test_icarename.py:8: RuntimeWarning: The unit for channel ICA 004 has changed from NA to V.

  raw.set_channel_types(mapping);

The unit for channel ICA 004 has changed from NA to V.

Now:

RuntimeWarning: The unit for channel(s) ICA 001, ICA 004, ICA 003, ICA 005, ICA 002 has changed from NA to V.

  raw.set_channel_types(mapping);

The unit for channel(s) ICA 001, ICA 004, ICA 003, ICA 005, ICA 002 has changed from NA to V.

@jaeilepp
Closes #3671

LGTM

Good to go from your end @jona-sassenhagen ?

All green, hit that button :D

Thanks @jona-sassenhagen

Thanks for reviews!

Yup


Add Radar plot.

It would be cool if one could see or in the best case compare test results as radar plots.(Wikipedia). There are already nice libraries for stuff like this(Example).

Interesting. But in this 4 dimensional chart, how should the information be presented?
This is an example from a random data set.

Since you've referred to this in the more general #60, I'm going to close this now.


Error during Module update.

When running update of the module, this error appears:

Not sure what causes it, but it happens every time.

No issue here, I tested it again. Could you remove the module and install it again (instead of updating) ?

That fixed it!


Models need TypeReference list

Node, Transport, Interface, Attribute, Terminal, Unit models need to have ICollection TypeReference (create new TypeReference object in Mimir). Configurations (database columns) 'TypeReferences' needs to be added. Update profiles. Cm -> dataModel in Mimir
Branch: feature/typeReference

PR ready for you @reliaboe https://github.com/mimir-org/mimir/pull/12


(Suggestion) Some new options to prevent bugs

Add 2 options/ways to join the game.
SpawnPlayerInstantly=true/false
Simply, if its false, player doesnt get spawned until next round is started but at least they are in the server.
AllowJoiningOnlyWhileShipInAir=true/false
Even more restricting but only allows new players to join if the ship is in the air... it still is better than having to restart the lobby completly and kicking 10+ players so one new can join :)
Right now this feels a bit buggy :o
and last option that would probably be good is:
OnlyShowServerIfJoinable=true/false
So it only shows the server if they are actually able to join.

fyi: "ShipLobby" has added this kind of feature.

which president is that

I'll probably add an option to have players join as dead/spectator if the game is already started at some other time


Image Preview issue?

In the last few days I am having an issue with image preview.. (have tried Bootstrap & materialize)
Some times... very rarely I see the image preview.

But most of the time I do not..?

The images are loading in the collection.... they don't seem to be picked up during the render

Also my text editor froala is not rendering any text... again its available in the collection. but not rendering.
Assuming these two issues are linked. as they both are the results of latest update to packages.

getting an error msg now with the upgrade
aldeed:autoform  upgraded from 5.4.0 to 5.4.1

Image thumbnails are no longer showing up unless I hit reload when on the collection editing page.

Fixed

not sure is this related... but I'm still getting the froala error. Text is loading..  maybe a rendering issue as the data loads?


Automatically restore EEPROM contents (if available) after flashing firmware (Trac #172)

When flashing over a control-board firmware:

Reset EEPROM to default values //(may not be necessary?)//
Check <user data>/configurations for an existing saved configuration/EEPROM.
If one exists, write saved EEPROM contents.

Migrated from http://microfluidics.utoronto.ca/microdrop/ticket/172
{
    "status": "closed",
    "changetime": "2015-02-11T16:17:17",
    "description": "When flashing over a control-board firmware:\n\n - Reset EEPROM to default values //(may not be necessary?)//\n - Check `<user data>/configurations` for an existing saved configuration/EEPROM.\n - If one exists, write saved EEPROM contents.",
    "reporter": "cfobel",
    "cc": "",
    "resolution": "wontfix",
    "_ts": "1423671437823147",
    "component": "dmf_control_board_plugin",
    "summary": "Automatically restore EEPROM contents (if available) after flashing firmware",
    "priority": "major",
    "keywords": "",
    "version": "0.1",
    "time": "2015-01-12T16:54:47",
    "milestone": "Microdrop 1.0",
    "owner": "cfobel",
    "type": "enhancement"
}

Trac update at 20150112T17:13:30: ryan commented:

Maybe users should be given the option to flash the EEPROM settings? For example, we could provide a prompt: "A previous backup of the configuration settings exists for this firmware version. Would you like to use these settings?".

Trac update at 20150211T16:17:17:

ryan commented:

Unnecessary since EEPROM settings are already contained in the calibration files for versions >= 1.0. Previous versions will have to manually recalibrate (or load a calibration file) after flashing firmware.

ryan changed resolution from "" to "wontfix"
ryan changed status from "new" to "closed"


Change AP Lost Beds to be based on Bed IDs

This removes the AP/TA model and table split for Lost Beds so that they can both be based on a bed reference rather than AP using total beds count.
After the migration has been run but before the Kubernetes deployment is completed any requests that need to read or write Lost Beds data which are routed to the pods from the previous version of the API will fail.  Unfortunately this seems to be unavoidable with JPA as we cannot control the SQL that's generated to read a Lost Bed to handle the possibility of the column no longer existing on temporary_accommodation_lost_beds.

 Change Manage to use rooms and beds - Back end


[TS migration] Migrate 'Section.js' component to TypeScript

Details
Migration of Section to Typescript + Fixes this console warning.
Fixed Issues
$ https://github.com/Expensify/App/issues/25024
PROPOSAL: N/A
Tests

Open any workspace -> click on Reimbursements, Settings, Cards, Bills, Members, Travel etc
Check that individual sections are displayed as before and make sure interactions work as expected (clicking, clicking and holding. etc)

Offline tests
N/A
QA Steps
Same as tests
PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome
android-web.webm

iOS: Native
https://github.com/Expensify/App/assets/46095609/3a010356-79bb-4666-83de-61e08e7b00a7

iOS: mWeb Safari
https://github.com/Expensify/App/assets/46095609/e41a512e-690f-4f2f-ac54-065034592c26

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/46095609/4238cfe4-e1a2-493d-b606-2a70295722a9

MacOS: Desktop
https://github.com/Expensify/App/assets/46095609/c0ac5cf5-cf2b-4d38-ba50-6116b84c0c45

@aimane-chnaif Done 👌

@aimane-chnaif Kind bump, this is blocking several other TS issues. I would appreciate a reviewer checklist on this one, thank you 😄

@aimane-chnaif Merged the newest main for you 👍

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

The predeploy.yml Github action seems to be consistently failing since this PR got merged. Do we think any of the changes here could have caused this?

🚀 Deployed to staging by https://github.com/mountiny in version: 1.4.23-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/thienlnam in version: 1.4.23-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Bot stop working after a few minutes

i let it work like 40 minutes and after it shows up 0 connected the whole time, maybe you need to set a restarter

there is already in config.js
	reset: 1800, // Minutes before server reset. (0 for none) (1800 = 30min)

Yeah like @Salvationdk sayed add the line or download the new version. Does other people using your acc or do you login on other devices when you use agar lvlgen?

@skillize once you have opened agar-lvlgen-master, you close other agario tabs, if you dont the bot cant start and will say 1:connected ; 0:spawned


Trusted Proxies

Hello, where can i find the config.php to add my trusted proxies and stuff? Because the api is always called by http instead of https through the proxy. Thanks.

You need to set the TRUSTED_PROXIES variable


Single quotes are messing with the command.

Was about to push the same. That works, or enclosing cmd with double quotes, whatever floats your boat. Nested single quotes doesn't work.


Use Numerical Value For Nonroot User To Avoid Additional Layer

Avoid user  (app) creation as it's creating a unnecessary additional layer and the user itself is not being used anyway. Instead prefer to use numerical values, i. e. as this PR is introducing with a uid of 1000 for a nonroot user.

CC @pbrisbin for a view on this. I have no real idea, but happy to push the merge button if those who contributed think its some good idea.

I get where you're coming from, and it's a good idea layer-wise, but the SPEC actually says specifcally an app user with id 9000:

Engines are always run as a user app with UID and GID of 9000, and never root.

https://github.com/codeclimate/spec/blob/master/SPEC.md#security-restrictions
I don't know how much they enforce this, and having any non-root user should satisfy the actual security concerns (I think?), but technically this would make the image violate the spec as it's currently written. So I'm a soft-no, myself.

thank, @pbrisbin for diggin into this. Of course we want to comply to the specs and thus leave it like it is.

[...]don't know how much they enforce this, and having any non-root user should satisfy the actual security concerns (I think?) [...]
me neither - and AFAIK it doesn't make as user "more secure" by giving him a UID way larger than 1000.

Engines are always run as a user app with UID and GID of 9000, and never root.
Hm, but the Dockerfile does not contain creation of a correspondig GID...

If the decision is to leave it as it is, but for slightly subtle reasons, maybe a comment in the Docker file would be useful?

Hm, but the Dockerfile does not contain creation of a correspondig GID...

:man_shrugging:

maybe a comment in the Docker file would be useful?

A comment at the top linking to the SPEC sounds pretty reasonable. There are a few things a Dockerfile is supposed to do, so that might be better then a comment specifically near or about the app user?

Happy with whatever comments you think are best.

I'll leave a comment on top of the  Dockerfile as suggested by @pbrisbin .

maybe a comment in the Docker file would be useful?

done :-)

Works for me!

Thanks!


Duplicate error with coord_genotypes.py

Hi,
Thank you for developing a great tool for PRS calculation.
I ran the coord_genotypes.py script with a bed file of 1000 genome data as a LD reference genotype file and encountered following errors
Working on chromsome: chrom_2 Traceback (most recent call last):   File "coord_genotypes.py", line 1836, in <module>     main()   File "coord_genotypes.py", line 1824, in main     hdf5_file=h5f, min_maf=p_dict['maf'], skip_coordination=p_dict['skip_coordination'])   File "coord_genotypes.py", line 1183, in coordinate_genot_ss     assert len(g_sid_set) == len(g_sids), 'Some duplicates?' AssertionError: Some duplicates?
Could you help me on this error?
Thanks,
SH

I recommend something between 100K and 2M SNPs.  You can find links to summary statistics on LD Hub (http://ldsc.broadinstitute.org/ldhub/) and other places.

Thanks a lot for introducing a great resource!
On Fri, Feb 1, 2019 at 2:58 AM Bjarni J. Vilhjalmsson <
<EMAIL_ADDRESS>wrote:

I recommend something between 100K and 2M SNPs. You can find links to
summary statistics on LD Hub (http://ldsc.broadinstitute.org/ldhub/) and
other places.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bvilhjal/ldpred/issues/34#issuecomment-459638171, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AkdJ1oXxPywkfaI_b0TRffsXZ1DXVeVWks5vI_O-gaJpZM4aCJvl
.


destroying event fails in mobile safari.

See:
http://liveweave.com/fVRBc8
Tried to destroy the event in safari yet it fails.  works on chrome.

I'm a moron, just looked through your source and you're attaching those events after image loads..  So i just changed the destroy to happen after window load instead of dom ready and it works now.


Add helpers to get settings values from env variables

I'm interested in reducing the distance from running startproject to having a deployable Django app, having recently had a number of interactions with junior devs interested in using Django but finding deployment a nightmare. Some of this is of course on the other side, on the PaaS of choice, but some of it can (and I think should) be done on the Django side.
I'd like to start small. This just adds a helper to get variables from the environment, with type conversion and defaults handled, and uses that helper on two values in startproject's settings.
https://groups.google.com/d/topic/django-developers/CIPgeTetYpk/discussion

PS. I think this looks great, but what do you think of approaching it a bit more open so it allows for a little customizability, these are my examples:
class Configuration:
    class NoDefaultValue:
        pass

    def __init__(self, store):
        self.store = store

    def process(self, name, default=NoDefaultValue, kind=str):
        try:
            val = self.store[name]
        except KeyError:
            if default == NoDefaultValue:
                raise ImproperlyConfigured("Missing environment variable {}.".format(name))
            val = default
        val = kind(val)
        return val

    def __call__(self, name, default=NoDefaultValue):
        return self.process(name, default, str)

    def str(self, name, default=NoDefaultValue):
        return self.process(name, default, str)

    def int(self, name, default=NoDefaultValue):
        return self.process(name, default, int)

    def float(self, name, default=NoDefaultValue):
        return self.process(name, default, float)

    def bool(self, name, default=NoDefaultValue):
        return self.process(name, default, self._bool)

    def _bool(self, val, default=NoDefaultValue):
        return val in ("True", "true", "yes", "Yes", "T", "t", "1", 1, True)

and we can use it like: from_env = Configuration(os.environ) and it gets to the point where this is at the moment.
Now for the custom stuff:
from_dict = Configuration({
    "int": "1",
    "str": "hello",
    "float": "1.22"
})

assert 1 == from_dict.int('int')
assert 1.22 == from_dict.float('float')
assert "hello" == from_dict('str')

or say you had some file called conf.ini somewhere were you keep your settings:
class INIDict:
    def __init__(self):
        # example from python.org
        import configparser

        self.config = config = configparser.ConfigParser()
        config['DEFAULT'] = {'ServerAliveInterval': '45',
                             'Compression': 'yes',
                             'CompressionLevel': '9'}
        config['bitbucket.org'] = {}
        config['bitbucket.org']['User'] = 'hg'
        config['topsecret.server.com'] = {}
        topsecret = config['topsecret.server.com']
        topsecret['Port'] = '50022'     # mutates the parser
        topsecret['ForwardX11'] = 'no'  # same here
        config['DEFAULT']['ForwardX11'] = 'yes'

    def __getitem__(self, name):
        # very easy example
        one, two = name.split(':')
        return self.config[one][two]

from_ini = Configuration(INIDict())

assert True == from_ini.bool('DEFAULT:Compression')
assert 50022 == from_ini.int('topsecret.server.com:Port')

This takes nothing, and gives everything. What do you think?

If we're going to go this route (which might well be a good idea) should we not be looking first at pulling-in (say) django-configurations, which already has a lot of this solved? e.g. https://django-configurations.readthedocs.io/en/stable/values/

If we're going to go this route (which might well be a good idea)

It's perhaps worth surfacing then that IIRC the way mod_wsgi works might present issues. It's been a while since I last checked in on it, and I can't remember the details though.

@kezabelle You mean mod_wsgi doesn't let you use environment variables? 🤔 Is that the idea of the default, so it would still work...
I asked if the django-configurations folks could input here or on the mailing list — I think goals+plan at least sketched there is needed.

You mean mod_wsgi doesn't let you use environment variables?

That's not entirely what I'm suggesting, and certainly not with any authority (as I say, it's been a while!) but I feel like there was some extra step(s?) involved. I'm bringing it up merely as something that would need to be checked and/or caveated if my recollection is accurate (which probably predates things like mod-wsgi-express being on PyPI, for example ...)

OK Thanks @kezabelle 👍

django-configurations looks odd, shouldn't we be looking at https://github.com/joke2k/django-environ for inspiration?

If we're going to go this route (which might well be a good idea) should we not be looking first at pulling-in (say) django-configurations, which already has a lot of this solved? e.g. https://django-configurations.readthedocs.io/en/stable/values/

Yes, investigation of more tools is imo a must. Also not everyone uses environment variables (nor are they necessarily a good idea at all since they might leak to subprocesses etc), so it might make sense to support reading from a variable file or similar.
If we are going down that route (and it's rather questionable that we should do it like that) we should also consider supporting the docker "standard" of loading the individual secret data via env variables suffixed via _FILE.
Fwiw, just as an example of possible projects in this realm:

https://github.com/funkybob/confucius
https://github.com/joke2k/django-environ
https://github.com/rochacbruno/dynaconf

Personally I find the ideas presented in the first one rather interesting and the last one is quite flexible and brings a few interesting things to the table (configuration via toml/yaml/ini files and layered configs)

@kezabelle You mean mod_wsgi doesn't let you use environment variables? thinking Is that the idea of the default, so it would still work...

mod_wsgi doesn't really care, that is more generally a problem of apache on it's own. If apache inherits the environment variables of the calling process it is just one set of variables. Ie if you use mod_wsgi to run two projects they will share those variables.

django-configurations looks odd, shouldn't we be looking at https://github.com/joke2k/django-environ for inspiration?

Please try to be productive. Why does it look odd and why do you think django-environ would be a better inspiration.
@carltongibson Personally I think we should close this PR and start from a ticket + ML discussion. Given that I expect strong feelings towards certain approaches I think a DEP might also be a good start. I don't see us anywhere the "implementation" phase yet.

@kingbuzzman presumably it's just the env variable that we'd consider here, but see the links django-configurations issue, where they're discussing using django-environ themselves. https://github.com/jazzband/django-configurations/pull/244 — so the thought would be, why aren't we looking to bring some/all of that in, rather than re-inventing?
I think we should probably move the discussion to the mailing list here... Ah, I see @apollo13 has commented exactly that whilst I'm typing. Let's close, discuss, and go via a ticket if we can find agreement to proceed.

@carltongibson Personally I think we should close this PR and start from a ticket + ML discussion. Given that I expect strong feelings towards certain approaches I think a DEP might also be a good start. I don't see us anywhere the "implementation" phase yet.

Happily agree; glad this PR at least got some conversation moving, and I hope it eventually ends with code!

@wlonk i copied django-environ and integrated it, still more work is required: https://github.com/django/django/compare/master...kingbuzzman:master


LLVM 11

A LLVM newer than 10.0 is required to build Chromium 86 (current dev version)

The newest released LLVM is 10.0.0, but 11.0.0 should have a RC very soon (I presume chromium needs >= 11).

Google fixed my "LLVM 11" query to "LLVM 12", so I trusted them :)

:-)  yes, master branch is heading for 12 already but 11 doesn't even have an RC yet, so consequently 12 is more visible than 11.

Update: LLVM 11.0.0-rc1 was released a few days ago: https://lists.llvm.org/pipermail/llvm-dev/2020-July/143839.html
There's already a draft PR: #94204


CB-20698 Select the default region for image on ycloud platform

See detailed description in the commit message.

LGTM, but maybe a few logs would be helpful later on when investigating


Some RPC endpoints return a -420 error when submitting for inclusion in app store

If an RPC provider doesn't have a method we expect, the CLI throws a -420 error. We should ensure we are using the most relevant and up to date RPC calls.

This has not come up in recent publisher feedback, so closing for now


[2.0-wip] Customize - Error in compilation Download

Go here: http://markdotto.com/bs2/docs/download.html
and click download with all options checked. The downloaded file has no css files.
Resolve issue:
uncheck "responsive layouts"
The thing is, whatever values you put in the variables, the output css is always the same with span1=59.999999px.
I guess this has to be fixed in the compilation script.
Win Firefox 10

just pushed all knew builder code...

ah i see 59.9999 will look into this..

thx!

plz also check the other issues on the grid builder.

These issues should be resolved now with the overhauled grid mixins and variables.


Adjusted weight fee calculation for capacity

Description
The adjustment weight fee seems to be miscalculated for capacity by including the base_fee and len_fee. According to the documentation on the documentation the adjusted_weight_fee is calculated:
 adjusted_weight_fee = targeted_fee_adjustment * weight_fee

We are currently adding both weight and length fees.
let adjusted_weight_fee = base_fee.saturating_add(weight_fee).saturating_add(len_fee);
let tip = Zero::zero();

fees = FeeDetails {
  inclusion_fee: Some(InclusionFee { base_fee, len_fee, adjusted_weight_fee }),
  tip,
};

https://github.com/LibertyDSNP/frequency/blob/501d622245cd2f886e13a3dd4c68ca1963c2bf19/pallets/frequency-tx-payment/src/lib.rs#L302
https://github.com/paritytech/substrate/blob/033d4e86cc7eff0066cd376b9375f815761d653c/frame/transaction-payment/src/types.rs#L47
Potential Solution
set adjusted-weight-fee to weight-fee.

After some discussions, we might have modified for Capacity. To not create confusion in the future perhaps the solution is to document the reasoning.

I think to avoid confusion with the meaning of these terms with respect to usage within balances pallet,
we should just return a number and thats all a consumer needs to know ideally (total capacity cost of a tx) ?


Fix split for issue #86

Changes splitting on newline to handle windows and linux newline characters

Closing this due to the 2.0 rewrite I had to do. So sorry that I didn't review this during my hiatus with this plugin. This change should also be no longer needed as this plugin now uses an Obsidian API method to retrieve the frontmatter


Don't use Yii DB deprecated methods in Migrator

Q
A

Is bugfix?
❌

New feature?
❌

Breaks BC?
❌

:+1:


bug fix for model loading from checkpoint

fix for bug introduced in https://github.com/nerfstudio-project/nerfstudio/pull/1501
model state dict will load incorrectly if any parameters contain "_model" in their name.
fix so that only the first instance of  "_model" is replaced

Can you please also fix it on line 373?

yeah, looks like the "module."

Can you run ns-dev-test?

yeah it passes the test vanilla pipeline test

But the linter fails, right? Just looking at the CI test results…


When showing proposals above current line: Show proposals bottom to top

VSCode Version: Code - Insiders 1.13.0-insider (afe47dc84467b487ce0079ff72f55e7ef4f7ebca, 2017-05-30T10:34:18.253Z)
OS Version: Darwin x64 15.6.0
Extensions: none

Testing #27315
When showing proposals above current line: To keep the selected item close to the cursor position, the proposals should be order bottom to top, such that, the selected one is at the bottom where the cursor is:

This is existing behavior, but I agree. I think so too.
Will look into what can be done here, but not for the May milestone.

@jrieken What do you think of @chrmarti's proposal?
Though initially I thought it would be nice to have the selected item close to the cursor, the change in order can confuse users who would expect alphabetically sorted items (most of the time)
Another idea is instead of changing the order, show selected item and n items before it instead of showing the selected item and n items after it. This way, the order stays, and the selected item is closer to the cursor

show selected item and n items before it instead of showing the selected item and n items after it.

Not sure what that means. Changing the sort order seems funky esp when I think about scrolling through the list

@jrieken Changing the sort order was what @chrmarti suggested.
What I am suggesting is to show

a
b
c
d (assume this is the current selection)
e (this is out of view)
f (this is out of view)

instead of

a  (this is out of view)
b  (this is out of view)
c  (this is out of view)
d (this is the current selection)
e
f

So that the current selection is closer to the current line

The same issue has been brought up in the monaco-editor as well.
https://github.com/Microsoft/monaco-editor/issues/560

d (assume this is the current selection)

This is not very realistic as in most cases the first item is selected. A different item will only be selected when the prefix/language/suggestion has been selected before

Good point.
I'll close this issue then.


chore: All ipcMain.emit eventNames should be standardized and typed

https://github.com/ipfs/ipfs-desktop/blob/d3897337466479ccf23c9fcfa1152d03dfb157ae/src/auto-updater/index.js#L143
https://github.com/ipfs/ipfs-desktop/blob/d3897337466479ccf23c9fcfa1152d03dfb157ae/src/auto-updater/index.js#L149
https://github.com/ipfs/ipfs-desktop/blob/d3897337466479ccf23c9fcfa1152d03dfb157ae/src/automatic-gc.js#L28
https://github.com/ipfs/ipfs-desktop/blob/d3897337466479ccf23c9fcfa1152d03dfb157ae/src/run-gc.js#L33
https://github.com/ipfs/ipfs-desktop/blob/d3897337466479ccf23c9fcfa1152d03dfb157ae/src/run-gc.js#L66
https://github.com/ipfs/ipfs-desktop/blob/d3897337466479ccf23c9fcfa1152d03dfb157ae/src/i18n.js#L33
https://github.com/ipfs/ipfs-desktop/blob/d3897337466479ccf23c9fcfa1152d03dfb157ae/src/daemon/index.js#L17
https://github.com/ipfs/ipfs-desktop/blob/d3897337466479ccf23c9fcfa1152d03dfb157ae/src/tray.js#L33
https://github.com/ipfs/ipfs-desktop/blob/d3897337466479ccf23c9fcfa1152d03dfb157ae/src/tray.js#L275
https://github.com/ipfs/ipfs-desktop/blob/d3897337466479ccf23c9fcfa1152d03dfb157ae/src/tray.js#L276
https://github.com/ipfs/ipfs-desktop/blob/d3897337466479ccf23c9fcfa1152d03dfb157ae/src/utils/create-toggler.js#L20
https://github.com/ipfs/ipfs-desktop/blob/d3897337466479ccf23c9fcfa1152d03dfb157ae/src/enable-namesys-pubsub.js#L28
https://github.com/ipfs/ipfs-desktop/blob/d3897337466479ccf23c9fcfa1152d03dfb157ae/src/enable-pubsub.js#L28
generated with:
git fetch --all
git checkout main
git pull
# then...
rg 'ipcMain.emit' src -n -m 999 --no-heading | awk '{print "https://github.com/ipfs/ipfs-desktop/blob/COMMIT_HASH/" $1}' | sed 's/:$//g' | gsed -e 's/:\([0-9]\+\)/#L\1/' -e "s/COMMIT_HASH/$(cat .git/refs/heads/main)/"

#2189


fix: fix error when converting IU claims

:tada: This PR is included in version 4.0.0-alpha.16 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.0.0-alpha.16 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.0.0-beta.2 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Typo fix in jaeger/README.md

a small typo in jaeger/README.md line 41
there are many such typos in the directory /incubator

/assign @unguiculus

/ok-to-test

/lgtm


Lot to TXT file

Is it possible to enable through Envt variable to make it so I can lot to STDOUT and a rolling LOG file.
With SMTP relaying/troubleshooting keeping a history in a plan LOG file is always handy.

Hi, not at the moment. Probably need to configure rsyslog to do that.
Would it be possible for you to use the docker log features instead? for example make dockerd log to the host syslog and let log rotation etc happen there.

Closing, please reopen or comment if you come up with some solution


Don't grab theme icons for scripts

When a node is extending a different class from it's actual type, the scene tree dock will show the script class instead. Extending a different class is a common use-case, e.g. you might have a Container-based node, but make the script extend Control to avoid problems with changing type etc. Scene tree displaying script type means that you don't know what Container type this node represents unless you hover it and check the tooltip. It's confusing and annoying.
This PR gets rid of this behavior. Custom types are unaffected.
Before

After

EDIT:
Fixes #76983

Fixes #76983 ?

This is fine as a temporary fix, but...
This was a part of the old get_class_icon method (but not of get_object_icon). I guess I might've been greedy when unifying those two methods. When we try to get a class icon for a script, it makes sense to fall back on the first built-in base class of the script. Whereas when we try to get an icon for an object, we should respect that object.
The method that you've changed deals with the script, so I think it should still do the look up for the base class in the theme. The discrepancy must be handled at a higher level, in EditorNode::_get_class_or_script_icon (unlikely, too general as well) or in EditorNode::get_object_icon. Can also be done in EditorNode::_get_class_or_script_icon but put behind a flag that only EditorNode::get_object_icon would set.

What unwanted side-effects would my change cause?
It's easy to ignore native class icons if you know the object's extended type, but this information is only available and cached in get_script_icon(). In any higher method there's a risk of slow lookups.
Note that _get_class_or_script_icon() already fallbacks to theme icon.

What unwanted side-effects would my change cause?

I suppose, scripts without custom icons will display a generic icon rather than an icon corresponding to their base type. And I mean scripts themselves rather than nodes with these scripts attached.

Also, this method is only called for objects with scripts attached, and Script can't have a script.

get_class_icon is called for strings with class names.

Just wanted to point out, that I have a PR which addresses the same issue: #76993.
If this gets merged the other one should be closed.

I looked at the code again, and just as I noted in a previous comment, _get_class_or_script_icon() already falls back to theme icon:
https://github.com/godotengine/godot/blob/8f175a8649fd5d83a8679651a2078ded496d61c0/editor/editor_node.cpp#L4308-L4318
And this part of code actually checks if the returned script icon is valid and tries further if not:
https://github.com/godotengine/godot/blob/8f175a8649fd5d83a8679651a2078ded496d61c0/editor/editor_node.cpp#L4285-L4290
So not sure what should I change. Am I missing something?

Ok I pushed something, but idk how to test it.

Thanks!

Cherry-picked for 4.1.2.


Maven: remove M2_HOME variable, do not persist conf

I have removed the M2_HOME environment variable, it is not used by Maven. Maven uses the %USERPROFILE%\.m2 directory. The conf directory does not have to be persisted. It contains only examples and is not used by Maven. Maven uses configuration files in the %USERPROFILE%\.m2 directory.

OK, I have reverted the conf change.


Sorry to bother you

What is the reason why the images I inserted did not work when using your theme, like this one:

I looked at your post and used the same syntax but it threw an error

can you share your image file?

yes,  i'm using Hugo Extended Version

the original url : http://gd-hbimg.huaban.com/ba964987def008e18f66b3bf89d73a6b94fc8532144c7f-yDphSc

can you share your image (.jpg) file?
& are you using Hugo Extended Version? or not?

yes,  i'm using Hugo Extended Version

the original url : http://gd-hbimg.huaban.com/ba964987def008e18f66b3bf89d73a6b94fc8532144c7f-yDphSc

It seems the issue is your .md file.
The file:
B:\Coding\Hugowebsite\blog\content\posts\瞒折腾*随折腾 .md*
Should be in this format:
B:\Coding\Hugowebsite\blog\content\posts\瞒折腾*index.md*
Please give it a try! 😃

It seems the issue is your .md file.
The file:
B:\Coding\Hugowebsite\blog\content\posts\瞒折腾\ 随折腾.md
Should be in this format:
B:\Coding\Hugowebsite\blog\content\posts\瞒折腾\ index.md
Please give it a try! 😃

thank you so much, i'll try it

Sure, let me know if you're still facing any issues or if you've succeeded

yes, it works. thank you sho much
btw, can't i use HTML tags?

Sure, let me know if you're still facing any issues or if you've succeeded

yes, it works. thank you sho much
btw, can't i use HTML tags?

Sure, let me know if you're still facing any issues or if you've succeeded

yes, it works. thank you sho much btw, can't i use HTML tags?

sorry, i got it , thank you so much

To insert HTML into Markdown in Hugo, you need to create a new shortcode:
You can read about it here:
https://anaulin.org/blog/hugo-raw-html-shortcode/

To insert HTML into Markdown in Hugo, you need to create a new shortcode:
You can read about it here: https://anaulin.org/blog/hugo-raw-html-shortcode/

To insert HTML into Markdown in Hugo, you need to create a new shortcode:
You can read about it here: https://anaulin.org/blog/hugo-raw-html-shortcode/

Thank you for your generous guidance.

You're welcome. It was my pleasure. 😄