I am unable to install plugin for ios, xcode version>8 through terminal. There is no document or hint how to add for ios, for android its asking for sender id but dont now how to install for ios. this is not working cordova plugin add<EMAIL_ADDRESS>try to add 1.9.2 or 2.0.x unable to add plugin

Expected Behaviour
Actual Behaviour
Reproduce Scenario (including but not limited to)
Steps to Reproduce
Platform and Version (eg. Android 5.0 or iOS 9.2.1)
(Android) What device vendor (e.g. Samsung, HTC, Sony...)
Cordova CLI version and cordova platform version
cordova --version                                    # e.g. 6.0.0
cordova platform version android                     # e.g. 4.1.1

Plugin version
cordova plugin version | grep phonegap-plugin-push   # e.g. 1.5.3

Sample Push Data Payload
Sample Code that illustrates the problem
Logs taken while reproducing problem

Sorry to be a jerk but I'm now closing issues that don't follow the issue submission guidelines. This plugin takes a lot of work to maintain and I can't afford the time required to solicit the required info from everyone.
I'm closing this issue but please feel free to re-open the issue if you provide the requested details from the new issue submission guidelines.
https://github.com/phonegap/phonegap-plugin-push/blob/master/.github/ISSUE_TEMPLATE.md


Release to Maven repository

using GitHub Actions
might be integrated as a third job in https://github.com/camunda-consulting/on-demand-call-activity/blob/master/.github/workflows/maven.yml
an additional build workflow might be needed for releasing a stable version

We discussed to remove final-name from asynch-service-task pom.xml

Open question: How to release a stable release?

See:
https://docs.github.com/en/free-pro-team@latest/actions/guides/publishing-java-packages-with-maven#publishing-packages-to-github-packages
https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#release


Feat/pyinstaller

This pr modified canvas_app s.t. the code can be packed with pyinstaller

Have you tested whether pyinstaller can work on this?

Yes, the exe works well.

The updator may have some unknown problem, but the updator.py should be modified anyway. Maybe I will fix it in another pr.

For executables the old updater doesn't work because it is based on git

Maybe we can just remove git update logic when building for executables.

It seems that I didn't solve the dependency well, currently the exe only works under the dir with canvas_mgr.py and etc. I will try to fix it.

Also we need to migrate some arguments from uvicorn to the executables, eg. the port and base_url

I think we can remove the updater support. It is not very helpful but needs git dependency.

do not merge until everything is set

I think we should first merge it to the dev branch otherwise current users will be affected


chore: Review and Update Analysis Rules

Is your feature request related to a problem? Please describe.
We have a couple of tickets around adding new analysis rules in. We need to actually inventory the current rule set, when it was last reviewed, and what is new since then to determine what we want to actually add in.
Describe the solution you'd like

We have a list of all the available analysis rules (Either in the readme or some other documentation file) and a checkmark or "X" to denote if they are enabled or disabled.
Disabled rules should have some kind of description as to why. Given historical context on some of them this may be tough so need to do our best on this.
Rules that have been introduced since the last update are reviewed and the team determines if they should be enabled or not.
The rules that are deemed as accepted are added into the tool

Describe alternatives you've considered
None
Additional context
Other tickets asking for new rules

#98
#90
#74

Linter rules Documentation - https://dart.dev/tools/linter-rules
Also seems like the "added in" documentation may be moved into each lint documentation page itself rather then an overview page.

These are my views about the new rules introduced in Dart 3.4:

annotate_redeclares: It is currently marked as experimental, I think we should revisit it once it is no longer experimental.
missing_code_block_language_in_doc_comment: I think we should add it in our next release.

It will enable proper syntax highlighting of Markdown code blocks, dart doc strongly recommends code blocks to specify the language used after the initial code fence.
Adding "none" as a language for those code blocks that don't have a defined language will suppress the warning.

unnecessary_library_name: I think we should add it in our next release.

Catches when a library does not need a library declaration, but one can be added to attach library documentation and library metadata to. A declaration of library; is sufficient for those uses.
Has a quick fix
Might need to consider removing library_names and package_prefixed_library_names.

Regarding https://github.com/VeryGoodOpenSource/very_good_analysis/issues/90, I do think we should include no_wildcard_variable_uses. It is not only marked as recommended but there is a warning specifying that the current usage will be breaking:

Wildcard parameters and local variables (e.g. underscore-only names like _, __, ___, etc.) will become non-binding in a future version of the Dart language. Any existing code that uses wildcard parameters or variables will break. In anticipation of this change, and to make adoption easier, this lint disallows wildcard and variable parameter uses.

Here's my opinion on some rules that we can add:

avoid_catches_without_on_clauses: As per the documentation of the rule itself: "Using catch clauses without on clauses make your code prone to encountering unexpected errors that won't be thrown (and thus will go unnoticed)." Therefore adding this rule will help our error handling be more meaningful.
no_literal_bool_comparisons: As per Effective Dart, don't use true or false in equality operations. Has a quick fix.

Also, to try and help fill the table about the reasons why are not using some rules, I can add the following:

always_put_control_body_on_new_line: Can conflict with the Dart formatter.
always_specify_types: Incompatible with omit_local_variable_types
avoid_classes_with_only_static_members: As per Effective Dart, there are natural use cases such as grouping constants in a class.
do_not_use_environment: We intentionally use environment variables to retrieve keys and other sensitive data.

@jsgalarraga I've added some of the given reasons to the table, thank you so much!
Regarding do_not_use_environment I've tried gathering more information before we have a solid reason. So, the rule doesn't catch Platform.environment but does catch, for example, String.fromEnvironment. Abstaining (current) from including it means there is no clear preference to use Platform.environment over .fromEnvironment. Whereas enabling it would state a clear preference for Platform.environment.
However, I'm currently unsure about the scenarios where String.fromEnvironment is preferred over Platform.environment and viceversa. There are issues from the Dart & Flutter team where themselves find the distinction between them confusing:

https://github.com/dart-lang/lints/issues/181
https://github.com/dart-lang/sdk/issues/27585

There is also a blog "Configuring apps with compilation environment declarations" about such environment variables, but it mainly explains .fromEnvironment with no reference to Platform.environment.
If we look at the original proposal of the lint rule, https://github.com/dart-lang/linter/issues/2096 a Dart team member (rakudrama) commented:

I have to say I don't really understand the motivation. The environment is baked into the app by the compiler. You can't do anything in the app to change the result, so it is more lake a configuration rather than (mutable) state.
One big advantage of, e.g. const bool.fromEnvironment is that since it is baked into the app by the compiler, the app can be optimized against the configuration, for example, tree-shaking all the dependent code.
This is not true of an alternative like a command-line option, which must not be optimized away in case the app is passed a command line with the option. Avoiding the 'environment' will always result in larger compiled apps.

To which I tend to incline towards due to the tree-shaking benefit.
In occasions, Platform.environment is preferred over .fromEnvironment, as in Dart Frog.
Knowing the above, regarding "We intentionally use environment variables to retrieve keys and other sensitive data." do you do so with Platform.environment or String.fromEnvironment and if so, why one and not the other?
P.S. I'm still evaluating the avoid_classes_with_only_static_members reason.

After reading through https://github.com/dart-lang/lints/issues/181 I'm a bit skeptical on adding unnecessary_library_name, it seems that according to goderbauer comment:

It is not clear to me why dartdoc behaves differently based on the presence of a library names.

It is unclear to me the where the current progress is on such effort. We could go forward with it (but maybe it's worth waiting a bit) and simply recommend users to rename their files or, if previously pointing to a path that no longer exists, updating such path.

Regarding do_not_use_environment, I find it confusing. One reason to prefer String.fromEnvironment over Platform.environment is that Platform.environment depends on the dart:io package, which doesn't work on Flutter web.

Thanks @jsgalarraga and @lishaduck I've updated the table and have a matching Pull Request https://github.com/VeryGoodOpenSource/very_good_analysis/pull/102 that updates the README table. I've added both of you as co-authors of the reasons you've found so that your counted as contributors.

Closing since v6.0.0 has been released. As per usual we're always open to reviewing some rules, if so, don't hesitate on telling us by opening an issue.


Add AES SIV ciphers to default provider

Checklist

[x] documentation is added or updated
[ ] tests are added or updated

Except for the lack of test data, this looks fine. Not sure why this depends on chacha...

Not sure why this depends on chacha...

Each cipher PR checked in means a rebase of any other cipher related PR's.
evp_enc.c, provider_algs.h, defltprov.c always need rebasing..

rebased and separated cipher low level implementation from dispatch

Moved out of WIP: and rebased.

ping

Thanks. Merged to master..


Sharing Express Route circuit among different subscription/tenant

> ExpressRoute authorizations can span subscription, tenant, and enrollment boundaries with no additional configuration required.
This seems to be limited only to Private Peering since the configuration requires VNET gateways. Is it possible to share an express route circuit among different subscription/tenant for Microsoft peering?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3cdb32c0-628d-0be2-f514-477d46dfa1b8
Version Independent ID: fa096059-2d16-30a2-1e8b-8b9671afcaa4
Content: FAQ - Azure ExpressRoute
Content Source: articles/expressroute/expressroute-faqs.md
Service: expressroute
GitHub Login: @jaredr80
Microsoft Alias: jaredro

Updated docs. #please-close


Workaround to validate socket buffer size before read/write

Following the thread in issues 234, I have a separate question:
Our system used epoll_wait and I have integrated io_uring to our system. One of the test cases I have is to set a socket buffer size to X, then pass in an allocated buffer with a greater size Y to do read/write. I would expect some kind of failure for the mismatched buffer sizes however io_uring completed the read/write successfully.  In this case, even if I remember the set socket buffer size X in my code, it's tricky to check it against the passed in real buffer size Y because the buffer passed in is just a pointer by the time it reaches io_uring_prep_writev(). Are there any better ideas, or is this test case even valid for io_uring?

you can store the buffer pointer and its length in a heap allocated struct, then store the struct address in the user data field, and then cast it back to the struct address when the operation completes.

Or just some tag/index for the buffer, depending on how you index them. Then you don't need heap data at all, but if it's all allocated on demand, then yeah I'd just wrap a buffer in a struct with some identifying info. Then you still only need one alloc, just like for the buffer itself.

Ok, currently the way I did it is already allocating the buffer to heap and save its size as well, so I can check it with the saved socket buffer size before calling liburing read/write.  The user data field is used for other purposes already in my code. Maybe this is the best option for now?

also remember pointers are only 48 bits, so you have 16 free bits.
i left shift the io_uring opcode and OR it with the pointer to my stream object (which holds all relevant state) in my network server.

Yes, you can take advantage of memory aligning facts, just be careful making assumptions that'd break on other archs or 32-bit if you care about the latter.


How to use matcher to see if set contains or map containsKey or map (for key) has value?

Looking through the examples in fflib_Match.cls and fflib_ApexMocksTest.cls I'm not seeing any way to

see if a set contains an entry
see if a map contains a key
see if a map for key k, has value v

My example is testing a VF controller that calls a FooService.doBar(..)  Hence, mocking a service FooServiceImpl, method doBar(map<ID,Foo.CustomType>)
I tried this (match on entire map)
// preamble to set up mocks and inject not shown ; it works fine
((FooServiceImpl) mocks.verify(mockFooSvc,1))
  .doBar(new map<ID,Foo.CustomType> {someId => new Foo.CustomType(arg1, arg2)});

but even though doBar is called with the map someId => new Foo.CustomType(arg1, arg2) (verified using debug), the verify method in ApexMocks comes back with
Expected : 1, Actual: 0 -- Wanted but not invoked: FooServiceImpl__sfdc_ApexStub.doBar(Map<Id,Foo.CustomType>)
So, bottom line - would be nice to see how to use matchers on sets (specific entry) and maps (entire map, hasKey, hasValueForKey, etc.) - especially without having to resort to custom matchers.

After some inspired searching on frup42 blog, I now see how to use fflib_ArgumentCaptor to solve the above on verifying maps.   Still seems as if there should be enhancement possibilities for more matchers on fflib_Match to deal with sets.

Another Apex quirk... This compiles fine:
List<Account> records = new List<Account>{};
List<Object> castUp = (List<Object>)records;
List<Account> castDown = (List<Account>)castUp;

But this doesn't compile, because: Incompatible types since an instance of Set is never an instance of Set
Set<Account> records = new Set<Account>{};
Set<Object> castUp = (Set<Object>)records;
Set<Account> castDown = (Set<Account>)castUp;

Likewise with Maps. So we can't write generic matchers for Maps and Sets, we have to have a specific matcher for the specific Typed Maps/Sets. This would be a lot of matchers, but not particularly useful for the majority of ApexMocks consumers.
So when the requirement comes up, we just let the consumer use captors or custom matchers knowing the specific Types in question in their test.


iOS 12 Safari breaks ASP.NET Core OIDC authentication

When logging into a site using Azure AD B2C Auth flow on IOS 12 I get caught in an infinite loop between my site and login.microsoft.com.
The application works fine on other browsers and operating systems.
I believe the issue may be related to:

https://social.msdn.microsoft.com/Forums/en-US/5f0aa4a8-9bfe-4be2-a366-77e6939ae36d/ios-12-safari-breaks-aspnet-core-21-oidc-authentication?forum=WindowsAzureAD&prof=required
https://bugs.webkit.org/show_bug.cgi?id=188165
https://hajekj.net/2018/08/31/beware-of-samesite-cookie-policy-in-asp-net-core-and-upcoming-ios-12/

As an interim fix I have set o.Cookie.SameSite = SameSiteMode.None; but this seems like a pretty suboptimal approach.
Is there a better solution?

@rhysawilliams2010 where did you put this setting? I've tried, but it keeps as SameSite.Lax:
            services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
                .AddAzureAD(options => {
                    Configuration.Bind("AzureAd", options);
                })
                .AddCookie(options=>
                        options.Cookie.SameSite = SameSiteMode.None
                    );

and

app.UseCookiePolicy(new CookiePolicyOptions
{
MinimumSameSitePolicy = SameSiteMode.None
});

I was having the same problems and solved it by creating a CookieAuthenitcationOptions object and adding a singleton to the services before adding authentication. Below is what I have in my startup class.
public void ConfigureServices(IServiceCollection services)
{
	//Added these lines of code
	CookieAuthenticationOptions cookieOptions = new CookieAuthenticationOptions()
	{
		Cookie = new CookieBuilder()
		{
			SameSite = SameSiteMode.None
		}
	};
	services.AddSingleton(cookieOptions);

	var loggerFactory = new LoggerFactory();

	services.AddAuthentication(sharedOptions =>
	{
		sharedOptions.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
		sharedOptions.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
	})
	.AddAzureAd(options =>
	{
		Configuration.Bind("AzureAd", options);
		AzureAdOptions.Settings = options;
	})
	//Added the options portion
	.AddCookie(options => options.Cookie.SameSite = SameSiteMode.None);

	...
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
	//Added this part
	app.UseCookiePolicy(new CookiePolicyOptions()
	{
		MinimumSameSitePolicy = SameSiteMode.None
	});

	app.UseSession(); // Needs to be app.UseAuthentication() and app.UseMvc() otherwise you will get an exception "Session has not been configured for this application or request."
	app.UseAuthentication();

	app.UseMvc(routes =>
	{
		routes.MapRoute(
			name: "default",
			template: "{controller=Home}/{action=Index}/{id?}");
	});
}

services.ConfigureApplicationCookie(options =>
{
options.Cookie.SameSite = SameSiteMode.None;
});
worked for me


upstream: add debug logs

Description: While debugging #5168 , added some additional debug info in logs locally. Thought would be generally useful so adding that PR.
Risk Level: Low
Testing: N/A
Docs Changes: N/A
Release Notes: N/A

/retest


Assignment 5: Backend

[ ] Select testing frameworks, linters, etc. and justify why we selected them

[ ] Write unit tests

Extra points will be awarded for additional, justified tools 🤡 and for 100% test coverage 🤡🤡

Testing: pytest, because it is de facto the standard for testing in the python world. The framework has rich ecosystem of libraries, plugins and integrations with other frameworks. Besides, it has well-written documentation, tutorials and big community. Github actions.
Linter: flake8, because it glues together pycodestyle, pyflakes, mccabe, and third-party plugins to check the style and quality of some python code. This linter is powerful for catching errors and also fast.
Formatter: black, because it is uncompromising Python code formatter. Black saves time from thinking about proper ways of writing things, thanks to strict black code style. More than that, black is trusted by famous open source projects and organizations: pytest, Django, Meta, Mozilla.

@SnejUgal @eivankin your opinions are welcome


Request: Put in option to allow > 1MB documents in a collection

Was wondering if it would be possible to allow > 1MB documents to be inserted into a collection?  We occassionally have objects that exceed that and we have to flip over to file storage for those, but we'd much rather use them as collections so we get all the features that come with that.  Is there a way we can override a collection's limitation or a repo's limitation for that?

Hi @dfarrNTST, there is no more this limitation in v4. There are only a recommendation to keep documents small as possible to be faster read/write and use more than one document (in different collections) to access only what you need at time.

Awesome...thanks!


Add open issues to docs

Single AZ NodePool not supported
Resources deletion not from tf not supported

/cc @sagidayan @EricPonvelle


cmd/go: should default to use mod=vendor flag if the vendor folder exists

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.11 darwin/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
What did you do?

Given a fresh install of go, there are no files downloaded in $GOPATH/pkg/mod.

What did you expect to see?

the application ran without downloading external dependencies.

What did you see instead?

The go tool downloaded all dependencies to $GOPATH/pkg/mod, despite the fact that the dependencies were vendored

I know this can easily be fixed by instead go run -mod=vendor main.go, but because the go tool is now being advertised as "context aware", I think this would be a good QoL change.

@JeremyLoy note that while the default is to ignore the vendor directory, you can relatively easily change that behavior with an environmental setting GOFLAGS=-mod=vendor. You could use that in CI, or could set it in a .bashrc or similar for day-to-day use if you want.
This is a new environmental variable in Go 1.11, where one of the justifications was specifically to make it easier to opt in to vendoring given some people would want that regularly (e.g., see  #26585 or https://go-review.googlesource.com/c/go/+/126656).
From the doc:
GOFLAGS
	A space-separated list of -flag=value settings to apply
	to go commands by default, when the given flag is known by
	the current command. Flags listed on the command-line
	are applied after this list and therefore override it.

One other quick note is that in 1.11, those downloads will be cached (so even if you don't opt-in to vendoring, it cuts down on how many times you would end up downloading dependencies).

I strongly agree with this proposal. If a project committed a vendor folder, this is a strong indicator that vendoring should be used by default. I can’t think of a workflow in which a developer would commit a vendor folder but prefer other developers to ignore it by default.
In other words, if a project decides to use vendoring, then the whole go tool should default to use vendor first, and download/cache only if not there.

By the way, this is part of what GOFLAGS was added for: https://go-review.googlesource.com/c/go/+/126656

GOFLAGS isn’t the right solution here. This is not a per-user / per-computer decision like “add debug flags”. This is a per-project decision that should affect all users building it. Currently, if a project uses vendoring, there is no way to let all builders use vendoring by default.

WhileGOFLAGS is a decent immediate workaround, I do want to stress the importance of the vendor folder as a part of this issue.
To put it bluntly, Github is not an artifact repository. At any given time, a repository owner can either

delete their account
delete a repository
force push deletions to master
remove a tag
change a tag

To avoid any of the above damaging your project, vendoring is a necessity, and should be treated as a first class citizen in the go toolchain.
There seems to be a rush to remove vendor from the go toolchain. It is still referenced as an "experiment" and there was a bit of swirl in even getting modules to support vendoring in its first release. Until Project Athens or equivalent becomes mainstream, vendoring should be fully supported (but never required).

@rasky

Currently, if a project uses vendoring, there is no way to let all builders use vendoring by default.

But we're talking about working in module mode here, correct? Or by "currently" do you mean GOPATH-mode? Because vendoring as a "first class citizen" continues to work in GOPATH mode, it's just that in module mode it is not the default.
@JeremyLoy

To avoid any of the above damaging your project, vendoring is a necessity, and should be treated as a first class citizen in the go toolchain.

There was a similar discussion over at https://twitter.com/_myitcv/status/1033824806930534400. Vendoring (as it was and still is in GOPATH mode) is one way of dealing with this problem. As I suggested, having a separate repo as a module download cache is another, which actually have a number of derivative benefits.
As you say, Athens (or indeed anything else that talks the published module protocol) are also solutions, solutions that in some cases try to solve even bigger problems.

There seems to be a rush to remove vendor from the go toolchain

I don't think this is quite accurate. In GOPATH mode (the default), vendoring works exactly as it has done up until now. In module mode (the opt in) the behaviour changes.
So for the record, in module mode I am against what is being proposed here, not least because of what I wrote above, but also because it confuses/complicates the rule that "vendor directories are totally ignored in module mode" which is particularly important when it to dependencies.

Because vendoring as a "first class citizen" continues to work in GOPATH mode, it's just that in module mode it is not the default.

Yes, I'm speaking about module mode. The point is that "not being the default" for projects that uses vendoring (that is, projects in which developers went through the process of calling go mod vendor and commit the vendor directory) is the wrong default. If a developers explicitly goes through the steps required to commit vendored dependencies, it is pretty obvious that they want those vendored dependencies to be used. People that don't use vendoring don't need to have vendoring explicitly disabled; they simply won't have a vendor directory in their project. By switching the vendoring support off in module mode, go 1.11 is making using vendoring more difficult for no reasons I can understand, without making things simpler for those who don't need or want vendoring.

There was a similar discussion over at https://twitter.com/_myitcv/status/1033824806930534400. Vendoring (as it was and still is in GOPATH mode) is one way of dealing with this problem. As I suggested, having a separate repo as a module download cache is another, which actually have a number of derivative benefits.

Thanks, but that is largely suboptimal. It requires a custom installation step to be repeated for each user, and also handle and commit binary files into the SCM which are harder to handle (especially with git) and review.

As you say, Athens (or indeed anything else that talks the published module protocol) are also solutions, solutions that in some cases try to solve even bigger problems.

I fail to see how Athens solves the needs of people using vendoring. AFAICT Athens helps with the issue that people can remove/sell GitHub repositories to other parties, and this can break builds and/or even cause security problems. This is not what vendoring is after. Vendoring is required in workflows that need 100% of the source code for a project committed under a single SCM, so that it can be fully audited, versioned, and built completely offline, without any dependency on any third-party service or installation. I deliver code to enterprises that want the code to be complete, not depend on third party services, and fully versioned with their existing code tracking tools. Vendoring solves this problem; Athens doesn't seem to.

So for the record, in module mode I am against what is being proposed here, not least because of what I wrote above, but also because it confuses/complicates the rule that "vendor directories are totally ignored in module mode" which is particularly important when it to dependencies.

You seem against adding a feature for people that need it for the sake of orthogonality. If you don't want or need vendoring, there's nothing in vendoring support that creates problems to you. Just use modules, your download cache, Athens or whatever you prefer. You will never have a vendor directory in your repos and nothing will break or be suboptimal for you. But if I need vendoring support and commit a vendor directory, why should vendoring support be disabled by default for me, causing more difficult builds for all involved developers?

If a developers explicitly goes through the steps required to commit vendored dependencies, it is pretty obvious that they want those vendored dependencies to be used.

That's not at all “obvious” to me. In fact, the current structure (in 1.11 module mode) is exactly the opposite: if a developer goes through the steps to commit vendored dependencies in module mode, it could just as easily be because they want to give their users the option to build using those vendored dependencies as an alternative to using modules.
Giving their users an option is not at all the same thing as providing an explicit recommendation.
Moreover, vendor directories can only reasonably work at the topmost level. If a developer makes edits within the vendor folder (intentionally or otherwise), they would effectively perform an implicit replace operation without surfacing that fact in the rest of the UI (such as in the output of go list).

If a developers explicitly goes through the steps required to commit vendored dependencies, it is pretty obvious that they want those vendored dependencies to be used.

That's not at all “obvious” to me. In fact, the current structure (in 1.11 module mode) is exactly the opposite: if a developer goes through the steps to commit vendored dependencies in module mode, it could just as easily be because they want to give their users the option to build using those vendored dependencies as an alternative to using modules.

I'm not sure that we can deduce anything from what Go 1.11. It's pretty obvious that vendoring wasn't even plan of the original module plan, and has been retrofitted at some point later in the process given different pressures. What we ended up with is basically non working for many vendoring use cases, hence this bug (and others).
Rather than discussing hypothesis made by people that don't vendor, I'd rather somebody that does use vendoring in production shows up and say that they absolutely don't want vendored modules to be used by default unless explicitly opted in (like Go 1.11 does), and explain us why with a small experience report. I for sure know this doesn't work for my use case as already explained in mine, and others have already chimed in.

Moreover, vendor directories can only reasonably work at the topmost level. If a developer makes edits within the vendor folder (intentionally or otherwise), they would effectively perform an implicit replace operation without surfacing that fact in the rest of the UI (such as in the output of go list).

That's perfectly fine for me at least. In fact, in my use case, vendoring support could go as far as completely subsuming the module download cache and/or go.sum. That is, it would be great that once you opt-in to "vendoring mode", all new modules are automatically expanded into the vendor directory, used by default, removed when they're not used, etc.

I'd rather somebody that does use vendoring in production shows up and say that they absolutely don't want vendored modules to be used by default unless explicitly opted in (like Go 1.11 does), and explain us why with a small experience report.

That's kind of my point, though: you're requesting feedback from one particular subset (package maintainers that choose to use vendoring) and ignoring another (package consumers, who have no choice in the matter in GOPATH mode, but do now have a choice in module mode).
We need experience reports from everyone — including package maintainers and consumers, and including both open-source and enterprise codebases.

@JeremyLoy, could you give some more information about your use-case?

The go tool downloaded all dependencies to $GOPATH/pkg/mod, despite the fact that the dependencies were vendored

Did you run go mod download after cloning the repository? Why or why not?
What is the impact of downloading the dependencies?

Do you intentionally want to bypass go.sum verification, or do you have in mind that the vendored dependencies remain unmodified?

Until [module proxies become] mainstream, vendoring should be fully supported (but never required).

Vendoring is still supported in Go 1.11, both in GOPATH mode and with -mod=vendor.
I am not aware of any proposal to remove it in 1.12, and would be surprised to see one at this point.

@rasky

It's pretty obvious that vendoring wasn't even plan of the original module plan, and has been retrofitted at some point later in the process given different pressures.

Please remember that among our gopher values is to “be charitable”.
The approach to vendoring in Go 1.11 does seem to have evolved with the implementation, but that doesn't mean it was “retrofitted”. A flag very similar to -mod=vendor was floated in #19234, and the ability to disable vendoring was discussed in #16562; as far as I am aware, both of those significantly predate the current module design.

@bcmills I'm currently using Go for enterprise application development, so I can give an experience report for that. You'll have to find someone else for the package maintainer report.
We currently vendor our dependencies using dep. We looked into converting to go modules, but found that the differences were too great to warrant a change right now, especially as modules are still in development.
We vendor for a variety of reasons, many of which were already stated here, but I will reiterate them for clarity.

a single deliverable - the client is able to take the codebase and build the application from source without internet access.
guaranteed stability - the leftpad problem simply cannot happen with vendoring. It is still an issue with both GOPATH and module development
security audits - the client is able to audit not just our source code, but our dependencies in a reproducible manner.

we also vendor tools such as gomock, goimports, swagger etc.
Now to answer your questions:

Did you run go mod download after cloning the repository? Why or why not?

no. because with the vendor folder, I should not have to.

Do you intentionally want to bypass go.sum verification

no, quite the opposite in fact. I imagined that go.sum would be a drop-in replacement for dep's Gopkg.lock

do you have in mind that the vendored dependencies remain unmodified?

yes.
Having to set an environment variable or constantly add a flag is a bit of a nuisance, but not a game breaker.   The biggest issue to me is that I expected go modules + vendoring to behave exactly like dep with vendoring (algorithmic changes not included)

It's pretty obvious that vendoring wasn't even plan of the original module plan, and has been retrofitted at some point later in the process given different pressures.

Please remember that among our gopher values is to “be charitable”.
The approach to vendoring in Go 1.11 does seem to have evolved with the implementation, but that doesn't mean it was “retrofitted”.

I'm sorry if it was borderline harsh, but anything related to "proposals" in Go often leads to a very frustrating experience, so much that I tend to steer away as much as possible from it and focus on where the community experience is vastly superior (eg: compiler development).
This said, I still think the quoted sentence is factually true. It was clearly stated in Russ' first blogpost:

This proposal keeps the best parts of go get, adds reproducible builds, adopts semantic versioning, eliminates vendoring, deprecates GOPATH in favor of a project-based workflow, and provides for a smooth migration from dep and its predecessors.

and has been repeated other times elsewhere. The vgo design didn't include vendoring; at some point, it was re-added to the picture, but there wasn't any discussion or attempt (at least that I could find) to rethink vendoring in the Go modules world. The fact that a default that doesn't work for people using vendoring was chosen, or that there are large overlaps between the vendor directory and the download cache is probably a consequence of not having fitted vendoring in the picture from day one.

@rasky I think you are right that the initial set of vgo blog posts initially proposed dropping support for vendoring.
However, there was then a fair amount of feedback from the community about the importance of vendoring. As far as I could see, that community feedback was clearly heard by the core Go team, which then resulted in the proposed plan being updated to actually retain support for vendoring with modules. The feedback was discussed in multiple venues, but this might have been the longest thread:
https://groups.google.com/d/msg/golang-dev/FTMScX1fsYk/uEUSjBAHAwAJ
...where within a week or so of the initial vgo blog post, the core Go team had switched to proposing retaining vendoring support with vgo/modules based on that community feedback.
In any event, sorry if my historical comments are not very interesting. A much more interesting question of course is what should the behavior be in 1.12+.

The vgo design didn't include vendoring; at some point, it was re-added to the picture, but there wasn't any discussion or attempt (at least that I could find) to rethink vendoring in the Go modules world.

Yeah, I can see that. Bear in mind that the module support in Go 1.11 is still preliminary: we know that it has some rough edges, and vendoring is certainly one of them.
I think it's important that we figure out a path forward, but it's not clear to me whether that will be to improve vendoring and better integrate it into module mode, or to improve the available module operations and deprecate vendoring entirely. I expect we'll try something in at least one of those directions for 1.12, but I think it's important that we have enough time to try out the improvements and make sure they work for those use-cases before they become the default.
In particular, because vendoring support in module mode is pretty awkward in 1.11, I think it's important not to try to push it as a default: I don't think it's the right design point yet, and I don't want folks to start relying on a design that really needs more thought.

a single deliverable - the client is able to take the codebase and build the application from source without internet access.
guaranteed stability - the leftpad problem simply cannot happen with vendoring. It is still an issue with both GOPATH and module development
security audits - the client is able to audit not just our source code, but our dependencies in a reproducible manner.

@JeremyLoy has made some great points here why vendoring is really needed in the software we build.
Without vendoring how are you planning to solve these points? Force everyone to host some caching/proxy thingy that would serve the dependencies transparently?
This would most likely compel developers to create various different solutions just like with vendor before (Godeps, govendor..) and thus split the community again while still not solve all of the points above.
What if some of the dependencies disappears and you don't have it in the proxy cache anywhere else? This would force developers to fix the dependency in their repository. However what if this is related to multiple versions with ongoing support? It would have to be fixed for all of them..
I'm really curious about your future solutions without the vendoring support that would satisfy the points above while at the same time not force us to manage extra stuff outside of repository to successfully build our Go programs.

@ondrej-fabry

Without vendoring how are you planning to solve these points?

That is a matter for a separate issue (perhaps #27618, and perhaps others as well). If you have specific requirements, please contribute an experience report describing both your use-case and how you address it today. (As I've said, it's not clear to me whether the solution will be to improve vendoring or to replace it, but experience reports will help either way.)
The matter at hand for this issue is whether -mod=vendor should be the default, in module mode, when the module's root directory has a vendor subdirectory.

Is there a single experience report, email or comment on GitHub issue that describes a real-world workflow in which the current default is correct? I have not seen any.

@rasky I don't think we have any experience reports for vendoring with module mode at all. As I've said repeatedly, I think it needs work before we can recommend any particular workflow. For now, if the module support in 1.11 doesn't work for you, don't use it. GOPATH mode is still supported and shouldn't get in your way.
If you want to influence the future direction of module mode, you need to share your actual use-case instead of just arguing that what we have today doesn't work: your current criticism is not constructive. We already know that what we have today doesn't work for you: we need to know how to make that better.

@bcmills I added a link to my comments (and by proxy, this issue) to the experience report page you referenced.

My experience with the current vendor behaviour has been as follows:
I've written  a (partial) drop in replacement for git in Go, primarily so that I can use it on Plan 9 where there's no access to the real git client. A user requested that I vendor my dependencies so that it can be bootstrapped without @0intro's rc script hack, which seemed like a simple enough enough request so I decided to oblige.
I copied the files to the vendor directory as I did to vendor with previous versions of Go and it didn't work. I ran "go mod vendor" which appeared to generate some ancilliary files for Go 1.11 like vendor/modules.txt. It appeared to work (I was inside my $GOPATH), so I committed and pushed the results. The same user then filed a GitHub issue saying that it was still trying to pull the code that was supposed to be vendored code from bitbucket instead of using the vendored library when doing go build -x. After some investigation, I found the -mod vendor flag and it resolved his problems. (Most of this took place at driusan/dgit#142)
I support this proposal because the current Go 1.11 behaviour:

Isn't how previous versions of Go worked.
Isn't what package maintainers expect.
Isn't what users expect.
Makes it difficult to build offline, even when all dependencies are vendored.

I think mod=vendor is too coarse: ideally the vendor folder should function more like an implicit set of replace directives, and we should automatically use whatever modules are found there (and fetch the remaining modules as usual).
That's certainly not happening for 1.12, but it's still on my radar.

How about:
Make it possible to specify "vendor" as the module version number string in go.mod. In that case take the module from the "vendor" subdirectory. Otherwise fetch the module as usual.
"go mod init" could add the modules in the "vendor" subdirectory automatically to go.mod with the "vendor" version definition.
That way it would be easy to see from go.mod which module comes from where. No need to look in many places.

@snabb Then you lose all version information and we're back to square one.
I'd just like to comment that I'd be totally opposed to removing the vendor folder. For me, it is absolutely necessary to make sure I still have project dependencies that might be taken offline. The vendor support so far in the new module system is ok but I wish it would copy the entire dependency's repository. I've had to write a tool to do this instead. https://github.com/nomad-software/vend

I think people have different use cases for the "vendor" directory.
In my common use case the packages in the "vendor" directory have local fixes, improvements or other customizations which are not available in the original repository. Therefore the vendored module can not have any version number which would correspond with the versioning in the original repository. I just want anything that is there to be used, overriding any other sources and thus the version number becomes irrelevant.
(I do realize that I might be abusing the vendoring mechanism to implement local modifications to dependencies, but it works well for that even if it was not the original planned use case.)

@snabb Take a look at the Replace directive in the mod file. This is exactly what you are describing. Then you could put your replacements in another directory.

@nomad-software Oh, this is great. I did not realize replace can be used for that. The documentation go help go.mod fails to mention it can be used to refer to local file system paths.

I think mod=vendor is too coarse: ideally the vendor folder should function more like an implicit set of replace directives, and we should automatically use whatever modules are found there (and fetch the remaining modules as usual).
That's certainly not happening for 1.12, but it's still on my radar.

So the vendor/modules.txt should be commit to VCS?

Yes, if you're committing the vendor directory you should definitely include vendor/modules.txt.

@bcmills
go dep only create Gopkg.lock, and other language tool such as maven, composer, npm alse only create one file xxx.lock.
So why go mod create two and what's the difference between vendor/modules.txt and go.sum?

@yanyandenuonuo I am not an expert dep user, but my understanding is that dep uses a manifest file (Gopkg.toml) and creates a lock file (Gopkg.lock) and also populates vendor. E.g., from a list in the dep doc describing the "state" that dep uses:

A manifest - a file describing the current project's dependency requirements. In dep, this is the Gopkg.toml file.
A lock - a file containing a transitively-complete, reproducible description of the dependency graph. In dep, this is the Gopkg.lock file.
The source code of the dependences themselves. In dep's current design, this is the vendor/ directory.

In other words, even with dep, there is a difference between a lock file and vendor.
With Go 1.11 modules, the go.mod files in a build encode the dependency requirements as well as provide enough information for 100% reproducible builds (and hence there is not a separate go.lock file or similar in Go modules, and go.sum is not a lock file either).
Go 1.11 modules also provide you with the option of populating vendor. This is not a requirement, but it helps with use cases such as "GitHub is down", a repo disappearing, etc., and it also helps with allowing the ecosystem to transition modules at different rates – older versions of Go such as 1.10 understand how to consume a vendor directory created by go mod vendor, so vendoring is one way for a module-based project to provide dependencies to older versions of Go that do not fully understand modules.
These two modules FAQs go into a little more detail, and are probably worth a quick read:

How do I use vendoring with modules? Is vendoring going away?

Is 'go.sum' a lock file? Why does 'go.sum' include information for module versions I am no longer using?

@thepudds Yeah, i had read the FAQS, but there dosn't state more detail about go.sum, and no state about modules.txt.
The wiki say go.sum is not a lock file, but it's state just like a lock file. It's seem like a alias name or format of lock file.
I think go.sum and modules.txt is repeat in effect.

@yanyandenuonuo, the topic of this issue is whether the go command should use the vendor directory by default in module mode. See http://golang.org/wiki/Questions for appropriate venues for general questions about modules and vendoring.

@bcmills If vendor/modules.txt is relate with build, so it's ok that discuss the difference between modules.txt and go.sum. If not, i think both of the file shouldn't be commit to vcs.

FWIW I am in the same boat of maintaining Go projects in a proprietary environment that has limited or no external network access. So I have needed to structure my projects in a self contained way. Before the Go module support, I had to have our custom Go tool for our waf build system handle doing a dynamic GOPATH for the project. We would also recommend using Glide. This allowed for non Go devs to clone to any location and build with confidence from the project with its vendored deps.  But we don't want the build to try and download. So each build has to make sure to set mod=vendor. I am totally onboard with the idea of respecting the project maintainers decision to commit a vendor directory and for that to be the default mode when detected.

but it's not clear to me whether that will be to improve vendoring and better integrate it into module mode, or to improve the available module operations and deprecate vendoring entirely.

I don't see why we would want to remove the option for vendoring when it is clearly a useful approach as suggested by the feedback from vendor users. If a project maintainer wants to use vendoring, then it should be propagated in the same way it is for GOPATH mode. What we have now is inconsistency between GOPATH and module modes.

In particular, because vendoring support in module mode is pretty awkward in 1.11, I think it's important not to try to push it as a default

It is only awkward because the behavior from GOPATH mode to module mode was not consistency retained. If the default mode could be detected as vendor then it is no longer about awkwardly needing to add a build flag. If a project maintainer doesn't want to have vendored deps used, they can remove the directory from the repo. And if a user of that project wants to ensure they always download, they can set the mod flag. Shouldn't we ensure the project owner has options? I see it similar to how a cgo project can choose to set default sane compiler and linker flags for the build, but a user still has the option to manually override those.

I have more feedback from real world experience.

At work we have a monorepo with a single vendor directory. Vendoring everything has been a very stable approach and we're likely to keep doing it for a while, at least until the tooling around modules reaches a similar point of stability.
The main problem we have with our GOPATH-based approach is that the tools we use for managing/updating the vendored dependencies seem to be persistently buggy/hard to use. I looked into replacing these with go mod vendor. My hope was that it would serve a dual purpose of both being more robust and also taking a small step toward in the module direction.
Unfortunately, we would need to use the GOFLAGS hack everywhere (local dev environments, build infrastructure, CI, etc) to ensure that all our go tool commands will use the vendored code. We never want to build the code without using the vendored dependencies.

I also have written/maintained some open-source projects. For library packages, whether or not they've been updated for modules, they never contain vendored code (as has always been best practice), so that's not relevant here.
For applications, either (a) they contain vendored code and expect a GOPATH workflow (no go.mod), or (b) I've updated them for modules and deleted the vendor directory. I have no problem requiring Go 1.11+ for building my applications.
If for some reason I updated an open-source application for modules and used go mod vendor to add a vendor directory, I would want my users to build with that vendored code (same as my work scenario). But I don't anticipate using go mod vendor for my open-source work at all.

I agree with what @JeremyLoy, @rasky, and others in this thread have said. It seems like using vendor for the main module, if it exists, is a much better default.

if a developer goes through the steps to commit vendored dependencies in module mode, it could just as easily be because they want to give their users the option to build using those vendored dependencies as an alternative to using modules.

I have a hard time seeing this practice coming into widespread use (as to justify the current default). It seems like it would be quite error-prone: wouldn't it be easy for the (Go 1.11+/module-using) developers to alter dependencies in the go.mod file (which various go commands will happily do) and then forget to update the vendor directory?

I may not have a complete breadth of knowledge (I've been wrestling with the tools a little), but this is my use & expectation of vendoring.
We have a small monolith repo of related Go projects, with a single vendor directory.  We are using go.mod to manage versions.  We are vendoring all our 3rd party packages and build tools (go-bindata and gomock at the moment).  The goal is to have 100% consistent builds both locally and in our CI environment, as well as 100% reliability (durability against dependencies going away, working offline).  It is also my hope that grabbing a shallow git clone will speed up the build process because all required resources will already be present.
The project that I am working on is to build tools to help our internal developers manage K8S / helm deployments.  We are a team of 5 at the moment, supporting (guessing) 50 developers.

I'm shocked that -mod=vendor isn't the default behavior. Why would I create a vendor folder and then not want it used? Let's follow the principle of least surprise here, and if the vendor folder exists, assume it's intended to be used.

I'm shocked that -mod=vendor isn't the default behavior. Why would I create a vendor folder and then not want it used? Let's follow the principle of least surprise here, and if the vendor folder exists, assume it's intended to be used.

I agree that it is surprising that go build does not use a checked-in vendor folder by default.

I'm running against this issue when deploying to Google AppEngine.
I have my vendor/ folder where a couple of modules reside on a private github repository.
A manual go build -mod=vendor works, but a go build that AppEngine launches does not use vendor/..

@hazcod, AppEngine supports module mode at this point, so it should not need a vendor directory. (See https://cloud.google.com/blog/products/application-development/go-1-11-is-now-available-on-app-engine.)

@webern, @ssoroka: see http://golang.org/wiki/NoPlusOne. Please keep comments productive.

@bcmills I’m not trying to be rude, but it seems like this entire conversation has fallen on deaf ears.
As noted above, there are valid use cases for having the project be a module, and still use the vendor folder for dependencies.
To completely dismiss @hazcod by saying “just use modules” completely misses the point of this entire thread.

@JeremyLoy, this issue is still open — it has not been dismissed or ignored, it just didn't happen in time for 1.13. However, for the particular use-case @hazcod describes, there is already a better alternative available: he shouldn't need to wait on this issue to be resolved in order to make progress.

That won't work for private dependencies - the AppEngine builder does not necessarily have access to private repositories.

For building locally I used go build -mod=vendor , but for appengine build I had to use a replace github.com/company/module ./vendor/github.com/company/module 🙁

how go test use -mod=vendor?

I'm extremely disappointed this wasn't prioritized and will not be in Go 1.13. I was looking forward to unsetting $GOFLAGS and deleting -mod=vendor from CI configs, scripts, Makefiles, etc.
After forcing so much toil on the community with the modules switch, this would've been the tiniest concession to show you cared.

@y0ssar1an (and others), please remember that the Go team are human and there's only so much they can do in one release window. In particular, @bcmills already has too many issues assigned for the release that's just seven weeks away.
Also note that this issue isn't as trivial as it might seem from the outside. Switching a default flag value would be an easy change, but likely not the best. @bcmills has outlined a better plan in https://github.com/golang/go/issues/30240, which has more details, and which is milestoned for 1.14.
If you would like to help, the best you can do right now is read that thread and give feedback on whether the plan would work for you, like @rasky did in https://github.com/golang/go/issues/30240#issuecomment-464080302.

Modules straight-up should not have landed without this. Forcing everyone to put -mod=vendor on every go build, go install, and go test command, or to set $GOFLAGS everywhere, was never an acceptable solution. I'm sorry to say, but this just reinforces the perception that Go is not a community-driven language.
If the community had a choice, what would they have picked?

A) Spend thousands of hours updating scripts, Makefiles, Dockerfiles, CI configs, shell configs, etc.
B) Wait 6 months for modules to be fully baked

To summarize:

You broke vendoring.
You did not clearly communicate that you were breaking vendoring. If you were honest about what you were doing, you would've called it Go 1.11 with Modules:tm: Breaks Vendoring Edition:tm:
Everybody in this thread had to learn the hard way that you broke vendoring.
An uncountable number of broken builds later, we're told that @bcmills and company are too busy to fix this.

Modules straight-up should not have landed without this.

@y0ssar1an
but modules have not landed. AFAIK, it will land in Go1.14 which is some moons away.
Go modules is behind a feature flag that you can opt into, warts and all

Starting in Go 1.13, module mode will be the default for all development.
https://blog.golang.org/using-go-modules

Forcing everyone

Of those people using modules (because nobody is forced to use modules; modules will only become the default in 1.14) it is demonstrably the case that not everyone has to use -mod=vendor.
As was stated before, for those people whose workflow has been broken/frustrated by a move to modules, yes, that is very unfortunate, but there are competing priorities here and limited resources.
A large part of the reason the default will only be switched in 1.14 is:

this issue of "vendoring" has not been fully addressed
documentation/examples/FAQs/etc are still lacking in places, including this one

Go is not a community-driven language

It is extremely unfortunate at best that that the term "community" continues to be used as a stick by (non-Google) people who feel like they haven't been listened to. Combined with the hyperbole of "forcing everyone", "spending thousands of hours", "wait 6 months for modules to be fully baked": these arguments/points simply become less rather than more convincing to my mind.
Contributing specific, constructive feedback/points is the way forward here. Please, let's all move forward on that basis.

@y0ssar1an
see https://github.com/golang/go/issues/31857

I support the notion that having a vendor folder would look for dependencies there first, with a resulting error message to the developer that "hey, we checked your vendor folder, but your vendor folder is out of date/missing certain dependencies in go.mod file, press Y to update them to your system $GOPATH/src directory or C to update your vendor directory, or N to do nothing. I think this makes it more user friendly, especially to someone who is new to Go.
Also, there does not seem to be a way to share the vendor folder across several packages in the same repository. For example, instead of github.com/username/foo/vendorIBM and github.com/user/bar/vendorIBM contain the same vendor folders, but having a vendor folder at the github.com/username/vendor level would provide dependencies for both foo and bar

Also, there does not seem to be a way to share the vendor folder across several packages in the same repository. For example, instead of github.com/username/foo/vendorIBM and github.com/username/bar/vendorIBM containing the same vendor folders, having a vendor folder at the github.com/username/vendor level would provide dependencies for both foo and bar

The way that we deal with that is to create a mono-repo for any projects that are expected to interoperate and share vendor.

@kliche the "shared vendor folder" you describe sounds just like a module cache, except for the fact that a module cache also know the exact version of you dependency. When you use "Go Modules" this is what you get today already. I can't see why you should add third party dependencies to your repo at all with the existing tooling around modules.

I work on a project that uses a custom source code re-writer to re-write some of the dependencies before using them in a build and vendoring was the easiest way to achieve this. I don't even commit the vendor directory into VCS. It is re-created with go mod vendor before every build. The project has a Makefile that makes it easy to add the -mod=vendor to all relevant commands so it is not as bad a solution but it would have been nicer if everyone could reliably just use go build without having to worry about where to read the dependencies from.
(To elaborate on the re-writer, I use a tool to replace all references to protobuf package with gogoproto allowing me to use gogoproto with dependencies that use protobuf internally)

Agree with the comments about this needing to be a project-wide setting, not a per-user configuration.
Is there a reason that -mod=vendor is not just the default? If people don't want to commit their vendor directory to git, that's their choice. But it seems that there would be no harm in always populating that directory by default (similar to node.js node_modules directory).

I stumbled upon this issue while googling and trying to understand why go build ignores the vendor directory even after adding it. I'm a huge fan of Go's explicitness and for this use case I tend to agree that having an explicit order of dependencies locations would be great. There is no need for -mod=vendor in my opinion, unless I'm missing something (didn't read the entire thread).

@amacneil @andreygrehov please see the very long thread above your comments; this is not a simple issue by any means. If you want to follow progress, see https://github.com/golang/go/issues/27227. Asking the same basic questions asked in the original post again is just making the thread more unbearably long for everyone :)

@mvdan thank you, I re-read this thread and to be fair it still does come across as if the Go team doesn't really understand this use case. However, after some digging through links I came across https://github.com/golang/go/issues/33848, where it appears there is a concrete proposal to support automatic vendoring, which is great news. Hopefully others coming across this issue can also follow this new proposal.

Closing in favor of #33848, which is a concrete proposal intended to implement the requested default behavior. (That proposal explicitly addresses the specific details and interactions that defaulting to -mod=vendor would imply.)

Duplicate of #33848

Note that #33848 now has a prototype implementation for review.


fix: post training and deploy project webhooks

The post-training webhook was failing because the model exceeded 400mb in size.
just as a sanity check, is it expected that the model becomes significantly larger once an image is added?

invalid


Confusion about shared_dirs and Laravel storage folder

First, I really enjoy and appreciate Deployer. Thank you so much for making it.  It has been working well for me.
The only problem I've had recently is that now in my Laravel 7 project I commit to git some special files into my storage/files directory, and then those don't seem available after deployment.
I think the problem happens because of https://github.com/deployphp/deployer/blob/29a643b62389542394c7b254f6c913f7191132ba/recipe/deploy/shared.php
I'm not sure that this is a bug... but maybe just a lack of documentation.
I probably just don't know what this means: https://deployer.org/docs/configuration.html#shared_dirs
In my config, my shared_dirs is still empty.
I think a lot of other people have been confused about similar points too (and I still don't understand):

https://github.com/deployphp/deployer/issues/572
https://github.com/deployphp/deployer/issues/875
https://github.com/deployphp/deployer/issues/957
https://github.com/deployphp/deployer/issues/1593
https://github.com/deployphp/deployer/issues/1647

Can you please clarify what shared_files and shared_dirs mean and whether they're related to my problem? Or maybe I'm accidentally not following Laravel patterns?
Thanks!
Environment

Deployer version: I'm not sure how to tell
PHP version: PHP 7.4.5 (cli)
Deployment target(s) OS: Ubuntu

Hi, thanks. Please, provide more info and context. I’m not really laravel expert, and don’t know storage is for.

Thanks for your response.
In routes/web.php, let's say I have:
Route::get('some_path/mydocument.pdf', function () {
    return response()->file(storage_path('files/anydocument.pdf'));
});

such that visiting example.com/some_path/mydocument.pdf should display the PDF hosted within /storage/files/anydocument.pdf
I'm intentionally not following the Laravel pattern of storing my file in /storage/app/public/, which is a special directory involved with a symbolic link, because I don't want it to be found there.
My /storage/files/anydocument.pdf exists within git (rather than being ignored) because I want to track version history.
Thanks.

@ryancwalsh From previous experience with deployment setups like this, I believe you will need to copy any new files within storage to the shared folder already on the server(s)?
Maybe list the /storage/files folder in the shared_dirs setting as that will copy it before it removes the storage folder in each release.

@bbashy Thanks. I'll try that on the next deployment. And how did you get your GitHub profile to say Vegan when I hover over your username?

@ryancwalsh Yeah let me know how you get on. I've been doing a lot of DevOps stuff over the years.
p.s. click on your photo (top right) and you should be able to set your status there. If not, on your profile near your photo.

@bbashy I finally had the opportunity to deploy again today, and unfortunately add('shared_dirs', ['/' . \App\Constants\Routes::STORAGE . '/' . \App\Constants\Routes::FILES]); resulted in:
deployer@ubuntu-s-1vcpu-1gb-sfo2-01:/apps/myproject$ ls -lah current/storage/
total 36K
drwxrwsr-x+ 5 deployer www-data 4.0K Jun 25 15:20 .
drwxr-sr-x  3 deployer www-data 4.0K Jun 25 15:20 ..
drwxrwsr-x+ 4 deployer www-data 4.0K Apr 21 17:12 app
lrwxrwxrwx  1 deployer www-data    5 Jun 25 15:20 files -> files
drwxrwsr-x+ 6 deployer www-data 4.0K Apr 18 22:03 framework
drwxrwsr-x+ 2 deployer www-data 4.0K Jun 25 15:22 logs
deployer@ubuntu-s-1vcpu-1gb-sfo2-01:/apps/myproject$ ls -lah shared/storage/
total 36K
drwxrwsr-x+ 5 deployer www-data 4.0K Jun 25 15:20 .
drwxr-sr-x  3 deployer www-data 4.0K Jun 25 15:20 ..
drwxrwsr-x+ 4 deployer www-data 4.0K Apr 21 17:12 app
lrwxrwxrwx  1 deployer www-data    5 Jun 25 15:20 files -> files
drwxrwsr-x+ 6 deployer www-data 4.0K Apr 18 22:03 framework
drwxrwsr-x+ 2 deployer www-data 4.0K Jun 25 15:22 logs

deployer@ubuntu-s-1vcpu-1gb-sfo2-01:/apps/myproject$ touch /apps/myproject/shared/storage/files/test.txt
touch: cannot touch '/apps/myproject/shared/storage/files/test.txt': Too many levels of symbolic links

I must be making incorrect assumptions about the sparse docs at https://deployer.org/docs/configuration.html#shared_dirs

@ryancwalsh I'd maybe opt for just using the resources folder. If it's in git anyway, it's no harm being in resources instead?
If not, just upload the file manually with a task. I use that to upload a new .env file to my servers.
task('upload:file', function () {
    upload('somefile.txt', '{{deploy_path}}/shared');
});

@bbashy Yeah I appreciate the idea. I similarly automatically upload .env on every deployment like that, and I was thinking my last resort would be to hard-code into this Deployer file that I want to upload this other file every time too.
Thanks!
P.S. I just figured it was worth opening this issue since I'm very likely misunderstanding something about the docs OR there is some very useful functionality missing. I'd definitely want to be able to have a specified directory automatically stay updated without specifying each individual file.

Can someone validate if this still a problem in v7?

Where's v7?

In master branch. First RC should be soon.

Hi, thanks for creating this issue.
I am also having the same problem with you and I think I found out what causes it.
If you look again at line 32 in this file https://github.com/deployphp/deployer/blob/55177c5b18440912076be6d03f700fc1973de56a/recipe/deploy/shared.php#L32
That command will run if shared directory doesn't exists in shared path and if release contains shared directory.
In other words, if your shared directory is already deployed and you add something to it, the command will not run and your update will not be applied.
To fix this problem, I'm creating a new task to change the flow of creating shared directory. I also made a change in shared files
Here's the task I made.
<?php
namespace Deployer;

use Deployer\Exception\Exception;
use Symfony\Component\Console\Output\OutputInterface;

desc('Creating symlinks for shared files and dirs');
task('deploy:full_shared', function () {
    $sharedPath = "{{deploy_path}}/shared";

    // Validate shared_dir, find duplicates
    foreach (get('shared_dirs') as $a) {
        foreach (get('shared_dirs') as $b) {
            if ($a !== $b && strpos(rtrim($a, '/') . '/', rtrim($b, '/') . '/') === 0) {
                throw new Exception("Can not share same dirs `$a` and `$b`.");
            }
        }
    }

    $copyVerbosity = output()->getVerbosity() === OutputInterface::VERBOSITY_DEBUG ? 'v' : '';

    foreach (get('shared_dirs') as $dir) {
        // Make sure all path without tailing slash.
        $dir = trim($dir, '/');

        // Check if shared dir does not exist.
        if (!test("[ -d $sharedPath/$dir ]")) {
            // Create shared dir if it does not exist.
            run("mkdir -p $sharedPath/$dir");
        }

        // If release contains shared dir, copy that dir from release to shared.
        if (test("[ -d $(echo {{release_path}}/$dir) ]")) {
            run("cp -ru{$copyVerbosity} {{release_path}}/{$dir} {$sharedPath}/" . dirname(parse($dir)));
        }

        // Remove from source.
        run("rm -rf {{release_path}}/$dir");

        // Create path to shared dir in release dir if it does not exist.
        // Symlink will not create the path and will fail otherwise.
        run("mkdir -p `dirname {{release_path}}/$dir`");

        // Symlink shared dir to release dir
        run("{{bin/symlink}} $sharedPath/$dir {{release_path}}/$dir");
    }

    foreach (get('shared_files') as $file) {
        $dirname = dirname(parse($file));

        // Create dir of shared file if not existing
        if (!test("[ -d {$sharedPath}/{$dirname} ]")) {
            run("mkdir -p {$sharedPath}/{$dirname}");
        }

        // Check if shared file exist in release
        if (test("[ -f {{release_path}}/$file ]")) {
            // Copy file in shared dir if not present
            run(
                "cp -ru{$copyVerbosity} {{release_path}}/{$file} {$sharedPath}/{$file}"
            );
        }

        // Remove from source.
        run("if [ -f $(echo {{release_path}}/$file) ]; then rm -rf {{release_path}}/$file; fi");

        // Ensure dir is available in release
        run("if [ ! -d $(echo {{release_path}}/$dirname) ]; then mkdir -p {{release_path}}/$dirname;fi");

        // Touch shared
        run("touch $sharedPath/$file");

        // Symlink shared dir to release dir
        run("{{bin/symlink}} $sharedPath/$file {{release_path}}/$file");
    }
});

If you have noticed, I used the cp -ru command to copy the directory and file. You can find out the detail of this command in this link https://man7.org/linux/man-pages/man1/cp.1.html
ps: I think this problem still exists in v7
Thanks
Environment
Laravel Depolyer: 0.3.5
Deployer version: 6.8.0
PHP version: PHP 7.4.3 (cli)
Deployment target(s) OS: Ubuntu 20.04

Awesome! What about creating PR fir v7?  If you can add some tests if will be cool too.

@antonmedv thanks for your response. I will try to make PR for this issue.


Release logrotate 2.0 to supermarket

@stevendanna Can we get logrotate 2.0 released to supermarket please?
cc @johnbellone

👍 I think this has been out there long enough.  We've only had one user mention the API change https://github.com/stevendanna/logrotate/issues/93 and they unfortunately never got back about their use case.

Done.


Make Group cells setting persistent when restarting spyder

Pull Request Checklist

[x] Read and followed this repo's Contributing Guidelines
[x] Based your PR on the latest version of the correct branch (master or 3.x)
[x] Followed PEP8 for code style
[x] Ensured your pull request hasn't eliminated unrelated blank lines/spaces,
modified the spyder/defaults directory, or added new icons/assets
[ ] Wrote at least one-line docstrings for any new functions
[ ] Added at least one unit test covering the changes, if at all possible
[x] Described your changes and the motivation for them below
[x] Noted what issue(s) this pull request resolves, creating one if needed
[ ] Included a screenshot, if this PR makes any visible changes to the UI

Description of Changes

This need to make the "Group code cells" setting for the outline explorer persistent
Issue(s) Resolved

Fixes #7736

Hello @bcolsen! Thanks for submitting the PR.

In the file spyder/plugins/editor/widgets/editor.py, following are the PEP8 issues :

Line 2826:45: E128 continuation line under-indented for visual indent

In the file spyder/plugins/outlineexplorer/widgets.py, following are the PEP8 issues :

Line 530:45: E128 continuation line under-indented for visual indent


Automatically destroy dependent records

Currently you have to manually add relations such as
has_many :animals,         dependent: :destroy
for all tenanted models to tenant.rb.
Idea: Extend milia to automatically add
has_many :my_tenanted_model, dependent: destroy
associations for all tenenated models.
Does anybody have an opinion on this?

Automating destruction of data doesn't seem wise to me. It's better that
the developers knows exactly what they are doing. Rails is full of examples
where such statements must explicitly be placed in each model. Danger lurks
ahead.
On Thu, Feb 2, 2017, 02:05 jekuno<EMAIL_ADDRESS>wrote:

Currently you have to manually add relations such as
has_many :animals, dependent: :destroy
for all tenanted models to tenant.rb.
Idea: Extend milia to automatically add
has_many :my_tenanted_model, dependent: destroy
associations for all tenenated models.
Does anybody have an opinion on this?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jekuno/milia/issues/67, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZDDOmx4MMNMv-xvAQJJhiWvAwYm1Eaks5rYapVgaJpZM4L06xm
.

I agree with @dsaronin on this one. Deletion of tenanted models should be explicitly defined.

If your applications grows over the years several developers will add more and more tenanted models. IMHO sooner or later somebody will forget to add the according has_many :my_tenanted_model, dependent: destroy which leads to orphaned records as soon as you destroy a tenant.
Can you imagine any situation where it would be wise to delete a tenant (i.e. company or organization) but to keep records which belong to this tenant? If you want this for recovery reasons you would probably want a consistent solution for all records e.g. by using https://github.com/rubysherpas/paranoia.


Question: DiscordBridge & Multichat Compatibility

So this is more of a Question then an issue. Was wondering if there is any support between the 2 mods currently? If not, if it's possible?
Multichat has the "global chat" for talking across all servers on the bungee network but it also has a "Local chat" for just the server your logged onto. Wondering if it would be possible to tap into the "Local chat"  and broadcast it to discord and vice versa.

a support for channels would be nice :)

by that you mean a diffrent channel in discord or a place holder for the channel name?

channels within minecraft like using this
https://forums.spongepowered.org/t/simple-chat-v0-3-0/11113
so the main channel or default channel is the only thing broadcast to discord maybe also all channels to discord for admin purposes.


Consider adding #[must_use] to MetricBuilder

I just updated my code to make use of tags (thanks for adding it, works great!). Now I have this code for example:
client.mark_with_tags("metric")
    .with_tag("key", "value")
    .send()
    .ok();

One thing that came up in the review was that it's easy to forget to call .send() on the MetricBuilder. And if you do, there's no warning.
So I was wondering, have you considered annotating MetricBuilder with #[must_use]? I gave it a quick try locally and it seems to work nicely, it results in a warning like this:

warning: unused cadence::builder::MetricBuilder which must be used

It prints that warning if you just have a mark_with_tags(...) and even when you have mark_with_tags(...).with_tag(...) (but forgot send).

Great catch! I'll add this soon

That was quick :). Thanks!
While we have the example in the description, have you considered adding an alternative to the send method that ignores any errors instead of returning a result? Currently, not calling .ok() on the Result results in a warning.

That method could be added. What do you think a good name would be? send_quiet()?

I've opened #65 for the method that ignores the results and doesn't require calling .ok() on the result of .send()


Missing documentation: '@Native' and 'external' (Question)

For example https://github.com/flutter/engine/blob/6c2dafed50770fed72d12d740cce27673d9172a7/lib/ui/painting.dart uses a lot of interoperability with C/C++ Flutter engine (Impeller). I didn't find any documentation for the annotation and key word:
  @Native<Int32 Function(Pointer<Void>)>(symbol: 'Canvas::getSaveCount', isLeaf: true)
  external int getSaveCount();

  @Native<Void Function(Pointer<Void>, Double, Double)>(symbol: 'Canvas::translate', isLeaf: true)
  external void translate(double dx, double dy);

This seems not to be the current ffi interop. (https://dart.dev/guides/libraries/c-interop) Compared with the FFI the code above is more compact and clearer.
What I found: https://github.com/dart-lang/sdk/issues/45451
Could you please link to a documentation or inform about the usage.

The external marker is something you can apply to a Dart function/getter/setter/constructor, similar to abstract in that it allows the declaration to not have a body. Unlike abstract the method can still be called, so the compiler has to provide an implementation for it.
So it's basically a way to say "compiler-supplied method body". How to attach a body to an external method depends on the compiler.
The annotation appears to be a dart:ffi feature, declared here, but it was released in the most recent version of the Dart SDK, so the guides may not be describing it yet.

Thanks for the information.
So the compiler needs in addition to the external marker the @Native annotation to know where/how to find the implementation (body) of C/C++/Objc (external) code. Is  the @Native annotation an optional syntax for ffi.lookupFunction?
Would it be possible to replace the following binding?
int closesocket(int s) => _closesocket(s);
final _closesocket = _ws2_32.lookupFunction<Int32 Function(IntPtr s), int Function(int s)>(
        'closesocket');

// replaced by
// (symbol: 'closesocket') = Default from external func name='closesocket'
@Native<Int32 Function(IntPtr s)>( )
external int closesocket(int s);

I can't actually find Native in the new docs, so maybe it's called FfiNative (https://api.dart.dev/stable/2.19.6/dart-ffi/FfiNative-class.html).
Overall, let's ask someone who actually knows dart:ffi. @dcharkes?

That new syntax is in 3.0, not 2.19. The 3.0 beta documentation is here: https://api.dart.dev/beta/3.0.0-290.3.beta/dart-ffi/Native-class.html

This seems not to be the current ffi interop. (https://dart.dev/guides/libraries/c-interop) Compared to FFI the code above is more compact and clearer.

Yes, this is the new shiny future. :)
The resolution from "native" to dynamic library is done in three ways.

Providing a mapping from asset-id to dynamic library. This is the intended use. However, this hasn't shipped yet. Please follow the following bug for updates.

https://github.com/dart-lang/sdk/issues/50565

Setting a resolver with Dart_SetNativeResolver from dart_api.h. This is only available in Dart, not in Flutter. Flutter doesn't export the dart_api.h symbols. This is how the Flutter code that you linked to uses @Native.
Lookup in the process. If the above two lookup methods fail, the symbol is resolved in the current process. Note that DynamicLibrary.open() does not load symbols into the process because the RLTD_GLOBAL flag isn't passed. If you want to use this approach, take a look at https://github.com/dart-lang/sdk/blob/main/tests/ffi/dylib_utils.dart#L49

For now, I suggest using DynamicLibrary and lookupFunction, until we have landed https://github.com/dart-lang/sdk/issues/50565.

Thanks @dcharkes and @lrhn for your answers.
This issue can be closed.

Questions answered.


encountered data format error when running DE analysis after batch correction

Hi
I encountered an Data format error when running Differential Expression with batch correction, but didn't without the correction process.
The error messages are described below:
警告:  'show_waiter' is deprecated.
Use 'waiter_show' instead.
See help("Deprecated") and help("waiter-deprecated").
 警告:  'hide_waiter' is deprecated.
Use 'waiter_hide' instead.
See help("Deprecated") and help("waiter-deprecated").
 警告:  Error in rownames_to_column: is.data.frame(df) is not TRUE
  113: <Anonymous>

Thank you.

Hi,
Could you please provide your session info and the header of the metadata table that you are using?
Best regards,
Daniel


Added info about redis-sentinel

Added three variables to config(redis.cluster.sentinel.master, redis.cluster.sentinel.sentinels and redis.sentinel.useDafaultPoolConfig):

Also updated dependencies and troubleshooting
PR Checklist

[ ] No broken links found using link-checker.

Linkchecker
Use the following command to check the broken links.
docker run --rm -it ghcr.io/linkchecker/linkchecker --check-extern http://<IP_ADDRESS>:4000

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Kyryl seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@ashvayka please feel free to close this PR, already merged into the master


Block: Remove dependency on dashboard & design system

Feature Description

When we originally created the new Web Stories block, we purposely re-used existing components from the dashboard and design system so we could ship this fast and iterate on it later.
That made it easy for us to have the same design as in the dashboard and to display stories properly using the <CardPreview>/<PreviewPage> component without having to re-invent the wheel.
Now that we're switching to displaying posters instead of actual previews in the dashboard (#5147), it is a good time to cut ties with these packages.
Not only that, it is also a good opportunity to simplify the block's code in other ways.
What I have in mind in total:

Remove ConfigProvider
We can simply access the window.webStoriesBlockSettings global
Merge useUserApi and useStoryApi into useApi
For useApi, use createContext from @wordpress/element instead of from design system.
Use UI components from @wordpress/components in the story picker instead of components from dashboard and design-system.
Use edit.css instead of styled components
Ensure we display store posters instead of using the full-blown preview components.
Simplify API interaction to remove things that we don't need.
This includes a lot of things, including totalStoriesByStatus and reshapeStoryObject
Maybe: Use wp.data.select('core').getAuthors() instead of fetchAuthors
(Blocked) Maybe: Use wp.data.select('core').getEntityRecords('postType', 'web-story') instead of fetchStories
Currently not possible due to https://core.trac.wordpress.org/ticket/53656 / https://github.com/WordPress/gutenberg/issues/33420 - unless we remove our custom namespace.

Once this is all done there should be no more dependencies to the dashboard and the design system package, nor styled-components, and the block bundle size should be significantly smaller.
Alternatives Considered

Additional Context

Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance Criteria

Implementation Brief

Wonder if we should do this as the same time https://github.com/google/web-stories-wp/issues/6634
Getting rid of these should do done at the same time
https://github.com/google/web-stories-wp/blob/9edf5fc1f38933a0bd33ec885ba003524d6a[…]ories-block/block/block-types/selected-stories/selectStories.js
As this is a WordPress / gutenberg context, we should reuse dropdowns and search for gutenberg.

Yeah I suppose we can, but in a separate PR. Will move it on the board & marked as blocked by this one.

Assigning to myself since I've been looking into this a bit locally already and have something shareable soon.

Re-sharing from Slack:
After some initial work to remove dependencies, I got the size of web-stories-block.js down from 2.9 MB (!) to less than 70 KB (!!!)

Both Search Stories and Search By Author have transparent backgrounds in their pulldown-type displays:


add yarn install during function initialization

Is this a BUG REPORT or FEATURE REQUEST?:
FEATURE REQUEST
What happened:
by default, the install container runs npm install --production --prefix=/kubeless, which has less performance advantage compared to yarn, would be nice if yarn install can be added as a choice during initialization.
What you expected to happen:
add yarn install.
Environment:
Runtime: nodejs8, nodejs6

hi @hwa123, thank you for the suggestion. Right now it is not possible to support more than one dependency system but we will take into account your feedback for future features.


Default C# source style matches decompiled style

I understand that the project uses the braces-on-same-line style. This just makes the source code match the decompiled C# code style (braces-on-own-line).
Default VB source already matches the decompiled style.

Thanks -- I appreciate the idea, and I missed the inconsistency.
However, I'd rather change decompiled code instead (seems easy enough).
I'll create a separate ticket for that a bit later.

Ok, I see. Nonetheless, I'd vote for braces-on-own-line, as this is more commonplace (I assume).
I'll close the PR for the time being. Thanks!

(I'll track the consistency fix under #90)


Change NLogLog to use wrapper type on all log calls to maintain call stack

Hey, I noticed that when using NLog the callstack layout renderer was not displaying the correct information. This is because the NLogLog wrapper must use the .Log(Type wrapperType...) to let NLog know that it is just a wrapper. I changed the NLogLog class to pass in the wrapperType to fix it.
Thanks,
Alden

Hey, have you had a chance to look over this again?

Sorry, it didn't notify me automatically when you updated the PR. :(


Add custom protostar path and source repo for upgrade command

I don't thin we are ever do this, closing


fixed bug: not hide footers' first column when hide table index

Sorry, I managed to merge the CSS, but not the JS. So, it would be fixed separately.


How to modify bounce error code ?

Hello @willpower232 ,
Does anyone knows how to modify bounce error code in postal?
I need to change 550-5.7.1 to be considered as soft and not had.
This issue am facing is related to this #266
Looking forward to read back from you.
Thanks

As far as I am aware, the situation has not changed since that issue so the only solution is to improve your reputation currently.


Add Result#and_then and Result#or_else as per #104

Considered adding runtime checks to make sure the value returned from the block is a Result as per the type signatures in the Rust docs, but decided to poll opinions first.

Oh lovely! Could you also write an integration spec showing off how it looks? Maybe in spec/integration/commands/try_spec.rb?

Sure thing! Will do that today.
Can use examples to highlight what happens if your block doesn't return a Result as well =)

Writing the integration specs made it very clear that not doing something about the return values of the blocks passed to and_then and or_else makes for a pretty poor API.
For now I combined the functionality of Rusts and_then with map and or_else with map_error; i.e. if the block returns something that is not of type ROM::Command::Result it is automatically wrapped in one.
I'm not a huge fan of the magic of this and I'm sure there are some issues with implementing monadic bind and map as the same function, but I can't think of any right now and I like this better than having to construct a ROM::Command::Result every time you use want to use #and_then.

Just some ideas.. The challenge is to come up with an API that doesn't feel too alien in the Ruby world.
# Option 1
result.and_then do |value|
  if value % 2 == 0
    Error("An even number")
  else
    Ok(value)
  end
end

# Option 2
result.and_then do |value, err, ok|
  if value % 2 == 0
    err["An even number"]
  else
    ok[value]
  end
end

# Option 3
result.and_then do |value|
  if value % 2 == 0
    [:err, "An even number"]
  else
    [:ok, value]
  end
end

I think option 2 looks good, it's explicit and doesn't require defining global functions. Auto-wrapping does feel like magic that's happening behind the scenes and when you look at and_then/or_else blocks it's not obvious that it's going to happen.

Ok, I implemented something close to number 2 but hung both #success and #failure off of a single passed in dependency:
result.and_then do |value, r|
  if value % 2 == 0
    r.failure "An even number"
  else
    r.success value
  end
end

Currently, r is just ROM::Commands::Result to which I've added .success and .failure.
For kicks, I added a spec for how this affects the implementation's adherence to the monad laws.
It's an easy step away from 2, but now I'm tempted to go all the way and just require folks to do:
result.and_then do |value|
  if value % 2 == 0
    ROM::Commands::Result.failure "An even number"
  else
    ROM::Commands::Result.success value
  end
end

If we couple this with a runtime error that checks the return value of the block passed to and_then or or_else we should end up with something pretty user friendly.
But...as I look at this more I think that with Rust as the example map and map_error may be better for the use case described in #104, especially since I'm a little fuzzy as to whether a ROM::Commands::Result::Failure is intended to be manually instantiated without a corresponding ROM::CommandError.
I fear I may be in over my head at this point, but I'm happy to continue plugging away/experimenting if you all think it's moving in a valuable direction @solnic @aflatter.
Thanks for entertaining the pull request, very excited about this project!

I like yielding result wrapper object to the block; definitely don't like exposing class methods (I'm anti-class interfaces in general).
Result could be promoted to be more generic, not strictly related to commands, so that command API can use it, and users can use it too when handling their own error/success cases.


Unusable instructions.

The install instructions fail to reach the result of actually installing this app. Typing the commands listed in the "install" section in the readme.md fails to install the application. Please add all the required commands to enter into a terminal. npm is not a recognized command in windows to begin with.

Perhaps it would be easier to supply a *.ps or *.cmd script that simply installs the functionality?


Little question about the code

Hi, I'm trying to add ProphotoRGB to my fork of this, but I'm running into a strange problem. I've defined the EOTF and inverse EOTF and the primaries and combed through all references to sRGB and kinda duplicated the code, just changing things to ProPhotoRGB. But for some reason, trying to convert even just between two linear RGB colorspaces ends with "no path between colorspaces" if I try to convert from, say, BT709 to ProPhotoRGB, however it works the other way around apparently. So even the very basic gamut conversion fails, but only fails in one direction.
I've probably missed something important, but what could it be? I see there's some function searching for "neighboring colorspaces" and whatnot but frankly I don't quite understand the code on a deeper level.
Do I have to keep the enums in some special order or something? I defined ZIMG_PRIMARIES_PROPHOTO as 30, but I also tried it as 13. Same result both times.
Any help would be appreciated even though I know you're not responsible for my coding problems. Just trying to understand the logic behind the code as in my mind I've done everything right.
The only thing I didn't do was mess with the stuff in the AVX512 named files, since I don't use or compile with AVX512. Was that an error?
Edit: If it's relevant, the same problem happens for both the new transfer and the new primaries. Whenever I use one of the new primaries as target, it finds no path. But I can use either as the source and it works fine. Also maybe relevant, I'm using zimg via the avsresize plugin for AVISynth... maybe it has something to do with it, I will investigate a bit.

Oh never mind, I figured it out. Had to adjust the all_primaries() functions and such.


When will have chinese version, etc

I am a chinese user. I am curious when will have chinese version and will have any other way to let chinese people can share internet access ? Because China can not use facebook and google.

Hi @liangyuheng16, thanks for your interest and sorry for the delay! I'll be posting more about this in the coming days, but for now please know that better support for China is currently one of our top priorities.
Closing this issue for now, but please feel free to subscribe to #1886 and #358 if you'd like to follow our progress in more detail on a couple of the ways we'll be adding better support for China soon.


Unable to handle Array

Hi, I have just started to look into your library and it look and the test cases are helpful.  I have a class object with array eg: Contact[] Contacts. Your library only supports IList and in GetExpression it throws an out of bounds exception in ProcessListStatement at
var type param.Type.GetProperty(basePropertyName).PropertyType.GetGenericArguments()[0];
Can you please let me know if there is a different way to handle this?

Hi ,
Yes,  In FilterBuilder.cs I had to change the method ProcessListStatement..
below for reference
        if(propType.IsArray)
        {
            type = propType.GetElementType();
        }
        else
        {
            type = propType.GetGenericArguments()[0];
        }

On Wed, 11 Nov 2020 at 14:16, Justinus Hermawan<EMAIL_ADDRESS>wrote:

Hi, have you found the solution for this?
I have the same issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dbelmont/ExpressionBuilder/issues/64#issuecomment-725447320,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJAWQ4LUAIHWVPYZM54WZ5TSPKMCLANCNFSM4LHHNTBA
.

--
Regards,
Karthik  P K

Hi, thank you. I just tried it but with no luck.
I modified some in the ProcessListStatement() method:
...
var propType = param.Type.GetProperty(basePropertyName).PropertyType;
var type = propType.IsArray ? propType.GetElementType() : propType.GetGenericArguments()[0];
...

My test case:
var indexes = new Dictionary<long, Index>();
indexes.Add(1, new Index { Position = 1000, Values = new object[3] { "Welly", "Chandra", 26 } });
indexes.Add(2, new Index { Position = 1001, Values = new object[3] { "Darma", "Angelo", 25 } });
indexes.Add(3, new Index { Position = 1002, Values = new object[3] { "Abby", "Yeremia", 28 } });
indexes.Add(4, new Index { Position = 1003, Values = new object[3] { "Yonathan", "Gunawan", 22 } });
indexes.Add(5, new Index { Position = 1004, Values = new object[3] { "Aldy", "Santoso", 24 } });
var filter = new Filter<Index>();
filter.By("Values[1]", Operation.EqualTo, "Chandra", Connector.Or);
filter.By("Values[2]", Operation.EqualTo, 28);

public class Index
{
   public long Position { get; set; }

   public object[] Values { get; set; }
}

Error message:
System.ArgumentException: '1' is not a member of type 'System.Object' (Parameter 'propertyOrFieldName')


feat: added a bot presence

This PR adds a presence to the bot.

Guild count useless therefore we use that

Guild count useless therefore we use that

Yeah it's just there to look kinda nice


Maximize/Normal states when drag to/from the top in Win7

If I drag window to the top in my Win7, window maximizes, but icon Maximize/Normal doesn't change.
When I try to drag the window from maximize state (Windows 7 feature) I feel that I came back to WinXP, is is not possible. But If I drag the window from normal state to the left or right side, it is docked and undocked perfectly by draging.

This has been correctly listed as an issue by @inTagger on MahApps.Metro, which has a pull request pending for it. Might not get around to publishing a new nuget to update MarkPad until Monday though.

The MarkPad team will be waiting for the new package with anticip...
...
...
...pation!

aaaand it turns out that even though I've fixed it, we're not using MetroWindow or WindowCommands in MarkPad. Submitting PR now.


Fixes for source map of destructuring downlevel syntax

[x] Source map when initializers for the binding elements are not present
[x] Source maps when the default value for the binding element is present
[x] Source maps for parameter destructuring with default values
[x] Breakpoint spans for destructuring
[x] Source map for the first binding element some cases

Handles #1846 and #2213

:+1: