Relax type annotation requirement for literals and constructor initialization

In cases when a variable is initialized using a literal (String, int, bool, double, List, Map) or a constructor initialization type annotations do not contribute to type safety, but have net negative effect on code readability:
String greeting = 'Hello, World!';
double d = 4.5;
MyAwesomeWidget widget = new MyAwesomeWidget();
final Map<String, List<int>> measurements = <String, List<int>>{};

The following has as much type safety but better readability:
var greeting = 'Hello, World!';
var d = 4.5;
var widget = new MyAwesomeWidget();
final measurements = <String, List<int>>{};

Type annotations still contribute to type safety when the initializing expression is missing (i.e. null) or is non-trivial:
String greeting;
String greeting = null;
String greeting = condition ? hello : goodbye;
String greeting = fetchGreeting();

Using a type annotation can prevent an incorrect reassignment.

@sethladd I believe strong mode will not allow that. In strong mode you have to be dynamic to be able to do that.

Also, generally, I'd prefer using final as a variable's value rarely changes in practice. Today, with having to annotate the type, I am punished for using final (see the measurements example above).

Nice. Confirmed! (and I learned that DartPad now has a Strong Mode checkbox)

@Hixie , grand arbiter of Flutter style.

+1. We stopped duplicating the variable type last summer for final variables (but not for var variables.) I'm not aware of any problems this has caused now that the analyzer issues have been resolved.

I think having types everywhere is a simple rule. Simple rules lead to better habits and thus more efficient development because you don't have to think about it.
It also makes maintenance easier. For example:
   // day 1
   var greeting = 'Hello';

   // day 2, let's move that into a function:
   var greeting = getGreeting(); // oops, now we have to give the type.

Having types sometimes be on the left and sometimes be on the right makes the code harder to read:
  String greeting = getGreeting();
  var greetings = <String>['hi', 'hello'];

Several aspects of our style are explicitly about being able to scan code by just reading the left edge. You can tell where blocks and expressions begin and end, you can tell the types of all the variables, etc, all by just scanning the left edge. "var" works against this, because now you sometimes have to go to the right to see what types are around. In the example above, scanning just the left edge you might be left with the impression that there's a String and some cheap variable, as opposed to a String and a potentially quite expensive Map.
It also makes code annoying inconsistent. For example:
String greeting1;
String greeting2 = condition ? hello : goodbye;
var greeting3 = 'Hello';
String greeting4 = fetchGreeting();

It doesn't work for int and double literals because the literal isn't enough information to be able to tell if the variable should be "int", "double", or "num". (We don't want to have to use num because we want to avoid polymorphic call sites.)
It also won't work once we have union types, for similar reasons.
Once we have a formatter, we can make the formatter turn var into explicit types for you, so if you really want to avoid giving types while coding, we should probably just go down that route. That way you don't have to worry about it when coding, but the code itself still has all the readability benefits.
Now on the other hand what would be really good would be if the compiler could do the opposite: enforce a declared type on a literal. For example, if I say:
   final Map<Metric, double> measurements = {};

...then the compiler should force the created map to be a Map<Metric, double> rather than a Map<dynamic, dynamic>. (You should still be able to force it to the latter explicitly, of course.) This would solve a whole bunch of problems at once, for example, it would allow:
   double x = 0;

Note that our style guide only really applies to people working on Flutter framework code. Flutter consumers can have their own style.

It also makes maintenance easier.
Once we have a formatter, we can make the formatter turn var into explicit types for you, so if you really want to avoid giving types...

The problem is not having to type. I believe code size is second to readability. Readability contributes to maintainability more than conciseness. So I would actually not want the formatter to do the conversion.

Having types sometimes be on the left and sometimes be on the right makes the code harder to read

I agree that this is a tradeoff, but a tiny one. I've seen a lot of code that mixes types with var and it has yet to become an issue, other than when the expression type is not obvious, which is addressed by this proposal. The only issue was that you used to lose type safety in the pre-strong mode world. Today, that issue has been eliminated.

able to scan code by just reading the left edge

What good are types without knowing what variables they are attached to? I would actually prefer type annotations on the right, because the variable's name and location are more important than its type. In fact, types on the left obscure variable declarations because the variable names are not aligned.

It also makes code annoying inconsistent

Not necessarily. The proposed rules is not to enforce var, but to make types optional. In your example it would be better to annotate greeting3 for consistency with the adjacent strings. Also, series of local variable declarations like that are rare compared to stand-alone local declarations. That mostly happens for field declarations, which are untouched by this proposal.

literal isn't enough information to be able to tell if the variable should be "int", "double", or "num"

It is. Every literal has a concrete type (1 is always int, 1.2 is always double), and if you want to pass an int or a double as a num, both are Liskov-substitutable. Additionally, strong mode ensures that you cannot assign a double to an int even if that int is declared using var (check this out - you'll have to click the bottom-right "Strong mode" box).

would be really good [...] if the compiler [...] enforce[d] a declared type on a literal

Having some responsible level of type coercion would be great, but not for your example. In your example you could have the literal express both the value and the type in one go. Type coercion is interesting in other areas, such as instantiating a custom implementation of Map using a plain map literal, but that's beyond the scope of this issue.

I think having types everywhere is a simple rule.

True, but in this case the tradeoff is too big for me. This rule would be much simpler than, say, the collection of rules we have for braces:

braces for long functions/methods
no braces for one line long statements
extra rule when no braces used
braces for map literals

I fundamentally disagree that omitting the types makes it more readable. Anything that requires that the reader think about what's going on by definition is harder to read than something that's obvious. var by definition means you have to think about what's going on compared to having an explicit type.
I read Dart code that uses var all the time (e.g. a lot of the Dart core libraries and libraries that we depend on like test) and I find it significantly harder to read than if the types are explicit.
The type is the most important part of the variable when what you're trying to do is understand what's fundamentally going on. It's critical that you see whether this or that variable is an integer, likely to be a smi, vs a String, vs a List of ints, vs a List of Maps of giant Elements or whatnot. You need the types to be able to reason about the likely performance of the function. If you scan the left edge of a function and you see only ints and ifs, then you know that you likely don't have any loops (maybe recursion), and that you likely don't have to worry about O(N^2) algorithms, and that you probably are using trivial amounts of memory. If you see that all the types are RenderObjects then you know that even if the function is short, you still need to check what calls it's making, and you know that you'll likely have to deal with lots of memory usage. If you see Lists around, you know that you should be wary of O(N) calls to, e.g., single, and depending on the type, you might determine that the memory usage is likely to be comparatively gigantic. If you see Maps around you know you have to be wary of people indexing into the map multiple times for the same key when they could be caching the value, and that you've essentially given up trying to keep things small. You can tell a whole lot just by scanning the left edge and seeing what types are around.
Variable names mean nothing when you're scanning thousands of lines of code. It's only when you're actually in the function editing it that you need worry about the actual names of the variables. Flutter's framework at this point is tens of thousands of lines of code. Scanning through the code is something everyone on the team should be doing regularly to get a feel for what the framework's footprint and structure are. You just can't sensibly do that if scanning through files requires jumping back and forth between type declarations, literals in assignments, etc.
Regarding some of your other points:

Our rules are intended to remove doubt in how to write the code. As such. we shouldn't leave things optional. Whatever rule we want, it should be clear cut for every case what the code should look like, such that a formatter can make that call automatically. The proposed rule does not lend itself well to this, since it would be context sensitive and in some cases would require judgement about what is more readable.

For the num/int/double case, var introduces inconsistency in that if you want an int-typed variable, you can use var, but if you want a num-typed variable, you can't. It's even worse with things like RenderBox vs RenderClip, where you often want the variable to be the less tight type, but basing it on literals would give you the tightest type. This essentially forces the rule to be more complex -- use var unless you somehow know the type you'd get isn't the right one -- which leads to even less consistent code.

I don't understand why you think having the literal's type determined from the variable's type would be worse than having the variable's type determined from the literal.

(I don't really see what you mean about the braces. Those all basically boil down to two rules: use braces for blocks, not statements or expressions; and distinguish empty blocks from empty maps. Even if they were complex rules, the existence of complex rules is an argument in favour of fixing those rules, not introducing more complexity. The "it's not worse than what we have already" maxim, due to the error on measuring how bad things are, over time leads to worsening of the average. The "is it the best we can do" maxim is how we get improvement over time.)

Since this is not about type safety, but personal preferences, I'd be ok with closing this. However, there are 4 people in favor of this proposal, so I'm hesitating.

Closing this for now. If we can get the VM to imply types from the declaration (LHS) to the definition (RHS) then I think we should consider removing the requirements on types on the definition. The left hand side needs to be explicit to enable code scanning, though, as described above.


(Angular/CDK) Expose more methods from interactivity-checker

I want to use some methods like isNativeFormElement, isHiddenInput, isInputElement and isAnchorElement from interactivity-checker, but I find they are not accessible from InteractivityChecker service.
eg: isNativeFormElement
https://github.com/angular/material2/blob/master/src/cdk/a11y/interactivity-checker.ts#L155
Can we move those functions into the InteractivityChecker service so that we can access them?

@jelbourn does it make sense to expose these? The checks seem pretty trivial.

@changLiuUNSW can you elaborate on why you want to use these functions?

We have some scenarios need to find first native form element and trigger focusing for accessibility purpose.

For your second and third points, why are isTabbable and isFocusable not what you want? Those methods are really more implementation details than anything universally meaningful.

@jelbourn
isTabbable  does not work for element with tabIndex= -1 , so it wont work for my second point.
Also  isFocusable  does not work for invisible element, so it wont work for my third point.

@jelbourn
If you guys are OK with it. I will create a PR soon.

Closing this since I think that it's both obsolete and something we don't want to do.

Hey @jelbourn! I was also hoping to use isPotentiallyFocusable. My use case is that I'm searching for the first focusable invalid element in a form, but the element may be in a collapsed section of the form, so isFocusable returns false because isVisible returns false. Would you be open to exposing isPotentiallyFocusable, or should I copy the implementation to our code base since that method isn't too much code? Let me know!

@vanessanschmitt I would be good with making isPotentiallyFocusable focusable, though I may want to bikeshed the name a bit to be less ambiguous.


Understanding Diffie Helman and Elgamal Asymmetric Encryption

Congratulations on publishing your first article @njerigitahi. Please go through the changes made by your peer reviewer and I to help improve the quality of your future articles.
Thank you for the review @jumamiller.


Adds Sheet/Range autoFilter option

This adds autoFilter per Sheet. Auto filter is this:

Example:
// set auto filter
sheet.range("C5:E8").autoFilter();

// clear
sheet.autoFilter(null);

There can be one auto filter per sheet.

This looks great too! It just needs tests and I'll merge it.

Published in v1.16.0. Thanks for the PR!


chore: Cypress update

Fixes test runs on jenkins.
Couldn't reproduce error with electron on mac.
Closes #4460

I've checked on mac - tests are starting in headless mode and passing 100%


feat: add Config\View::$enableConditionals to disable Parser conditionals

Description
Fixes #5831
CI3 Parser does not have conditionals. See https://codeigniter.com/userguide3/libraries/parser.html
CI4 Parser has conditionals, and it is difficult to distinguish if there is JavaScript code in templates.

add Config\View::$enalbeConditionals to disable Parser conditionals

The setting is for compatibility with templates that works on CodeIgniter3.

Checklist:

[x] Securely signed commits
[x] Component(s) with PHPDoc blocks, only if necessary or adds value
[ ] Unit testing, with >80% coverage
[ ] User guide updated
[x] Conforms to style guide

@totoprayogo1916 Thanks! These are typos. Fixed.

I found another solution: #5842
This PR might not to be needed.

#5842 was merged, so I think this is not needed.


FN UI is broken

Description
I have cloned the Github repo this morning, for an important demo we're setting up in Dubai.
If I start using the docker-compose, as soon as I access to the UI (port 4000)
I see a msg "Error: An error ocurred." on the top right side.
Then, I'm not able to create application from UI
Steps to reproduce the issue:

clone git repo
start entire env with docker-compose
access to UI

Describe the results you received:
I access to the UI (port 4000)
I see a msg "Error: An error ocurred." on the top right side.
and UI seems no more working.
funtion and applications create through CLI are not seen on UI
Additional information you deem important (e.g. issue happens only occasionally):
Happen always
Output of fn version (CLI command):
(paste your output here)

Additional environment details (OSX, Linux, flags, etc.):
Tested on Linux (Ubuntu and MacOS

Unfortunately, UI needs some love. At this moment it’s unmaintained. If you can help with that, it would be awesome.

A notice on the fn or fnproject/ui page would have been welcome. So we wasted some time trying to get it run.

yea, that is a good idea, sorry about that

https://github.com/fnproject/ui/pull/53

going to leave this open for triage reasons

Once the PR above is merged the main issue in this ticket will have been resolved. There are still some other things that I want to tidy up which I will continue with in fnproject/ui#52.


Fixed typo

@WSAyan : Thanks for your contribution to the Azure documentation! The author, @guyinacube, has been notified to review your proposed change.

@WSAyan Thatnk you for catching and fixing that!! @kfile
#sign-off

@JennieHubbard: I'm sorry - only the author of this article, @guyinacube, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.


Update to npm PropTypes instead of React.PropTypes

Since React 15.5.x we get a warning in the console:

"ERROR: 'Warning: Accessing PropTypes via the main React package is deprecated. Use the prop-types package from npm instead.'"

We need to update all of our components to https://www.npmjs.com/package/prop-types which is now a standalone Project.
Basically:

Install Prop-Types
Change imports.js
Update Code (Replace) React.PropTypes with PropTypes. Instead of using webpack + aliases we should go through all components and change it.

Has been done with #53


Release build stucked at "All eligible agents are busy"

Release build is stucked at screenshot below. I have a private pool with one build agent enabled and online.  Agent run in interactively / visible mode with auto-logon.

If I use a next agent pool with different agent server but with the same settings (capabilities), it works.
Thank in advance for help.

@mariankral, do you mean to say that the agent is actually not busy but still the UI is saying that its busy and agent is not picking up the job?  If yes, can you please share the link to the release & its environment so that we can check logs for your account/project/release id/release environment id?

Yes, agent is not busy and UI is saying that its busy.
I can not share the link.

Can you please send the link at RM Customer Queries<EMAIL_ADDRESS>

This is not a task issue and hence should not be discussed here. You should report the problem here. https://developercommunity.visualstudio.com/spaces/21/index.html


Support v0 and v1 nodenetsvc api for ncproxy

This PR adds support for "v0" and "v1" nodenetsvc api. Previously, the proto package name was changed to "nodenetsvc.v1". However, this was never adopted.
This support works by attempting to call the v1 version of the api and if the call returns the grpc code "Unimplemented", then we fall back to the v0 api instead. I considered a different implementation here where we would decide which api was being used when ncproxy is started up. However, there's not a great way other than making a call to determine which api is being used and if the nodenetsvc agent updates to the v1 api, ncproxy would need to be restarted to be used with the new api. This does mean that if using the v0 api, there are two calls made for every one request to ConfigureNetworking.
This PR is currently based on https://github.com/microsoft/hcsshim/pull/1797 and will be rebased when that PR is merged.

You have an extraneous commit.

What about other calls like ConfigureContainerNetworking, PingNodeNetworkService, and GetHostLocalIpAddress? Do they need similar handling?

They would, but we don't actually use those calls ever.


Fix blank gender

This is to fix #5

@courtneymiller2010 Thanks for the PR. Sorry for the slow response, I've been on vacation.


network-relation-changed failed due to lxc-docker-{{version}} not a thing.

I found a bug with the latest code, lxc-docker-{{verison}} went to docker-engine
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40 TASK: [Halt docker service] ***************************************************
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40 failed: [localhost] => {"failed": true}
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40 msg: service not found: False
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40 FATAL: all hosts have already failed -- aborting
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40 PLAY RECAP ********************************************************************
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40            to retry, use: --limit @/root/site.yaml.retry
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40 localhost                  : ok=9    changed=6    unreachable=0    failed=1
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40 Traceback (most recent call last):
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40   File "/var/lib/juju/agents/unit-docker-1/charm/hooks/network-relation-changed", line 14, in
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40     main()
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40   File "/var/lib/juju/agents/unit-docker-1/charm/hooks/network-relation-changed", line 11, in main
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40     hooks.execute(args)
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40   File "/var/lib/juju/agents/unit-docker-1/charm/src/ansiblecharm/ansiblecharm/runner.py", line 216, in execute
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40     tags=tags, verbosity=verbosity, module_path=modules)
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40   File "/var/lib/juju/agents/unit-docker-1/charm/src/ansiblecharm/ansiblecharm/runner.py", line 129, in apply_playbook
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40     subprocess.check_call(call, env=env)
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40   File "/usr/lib/python2.7/subprocess.py", line 540, in check_call
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40     raise CalledProcessError(retcode, cmd)
unit-docker-1[3649]: 2015-09-15 18:04:59 INFO unit.docker/1.network-relation-changed logger.go:40 subprocess.CalledProcessError: Command '['ansible-playbook', '-c', 'local', '-v', 'playbooks/site.yaml', '--tags', 'network-relation-ch
anged', '--module-path=/var/lib/juju/agents/unit-docker-1/charm/modules']' returned non-zero exit status 2
unit-docker-1[3649]: 2015-09-15 18:04:59 ERROR juju.worker.uniter.operation runhook.go:107 hook "network-relation-changed" failed: exit status 1

Corrected as of tag v0.2.2
Thanks for finding/filing this bug @mbruzek


VS Add Reference error: A reference to 'StereoKitC_UWP' could not be added.

Created a new project for HoloLens 2 using the StereoKit UWP template in VS 2019 and 2022. I added the StereoKit, StereoKitC, and StereoKitC_UWP to my solution because I am tweaking the C++ at the moment, experimenting.
When I try to reference the StereoKitC_UWP as it is in the examples, I get the error. Naturally, if I build the StereoKit code to a nuget package and use that, I have no issue. But I am directly referencing the code as is done in the example projects. Note: I noticed that VS 2019 and 2022 are indicating a problem with the reference as it is in the current examples.
My guess is you manually edited the references to add it in?
Platform / Environment
Windows 10 and Windows 11, Visual Studio 2019 and Visual Studio 2022.
Logs or exception details
Error text: A reference to 'StereoKitC_UWP' could not be added. The method or operation is not implemented.
Logs are super helpful, please include them if they're at all relevant!

If you have an exception, details about that would also be essential.

I had a fair bit of difficulty with directly referencing native projects from C# projects. I've not been certain if it's something with the specific project files, or something a little more fundamental!
In the StereoKit .sln, I don't reference the native projects directly, but instead rely on the build 'dependencies functionality' to ensure things get built in order. I then manually copy some of the output files using MSBuild/XML commands, so you'll almost certainly need to modify your .csproj to work in this way. Check out StereoKitTest.csproj for what I'm doing. I'm not sure how well this translates to external projects, probably doable, but there may need to be some path modifications? I think I use $(SolutionDir) a bunch, and that may not be as durable in this case.
This isn't a use-case I've covered, so you're trailblazing here :)


[SPARK-17713] [SQL] Move row-datasource related tests out of JDBCSuite

What changes were proposed in this pull request?
As a followup for https://github.com/apache/spark/pull/15273 we should move non-JDBC specific tests out of that suite.
How was this patch tested?
Ran the test.

Test build #66071 has started for PR 15287 at commit 5e5a6f1.

Thanks - merging in master.

Test build #66071 has finished for PR 15287 at commit 5e5a6f1.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class RowDataSourceStrategySuite extends SparkFunSuite with BeforeAndAfter with SharedSQLContext

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/66071/
Test PASSed.

Merged build finished. Test PASSed.


Single picture for multiple components

It looks like I cannot choose a component picture from already uploaded pictures for other components.
Use case is when, for example, I have multiple resistors. They all have one picture, but are essentially different components. I don't want to upload one and the same photo for each entry, but rather use a already uploaded one.

This would be great for things like attachments too. I was looking at django-filebrowser, although it's aimed at doing this in the admin panel.

See https://github.com/inventree/InvenTree/pull/639


Enhancing UpdateLightExtensions to support Dimming and DimmingDelta

Hi Michael,
I took the liberty to extend the UpdateLightExtensions with two new static methods:
public static T SetBrightnessDelta<T>(this T lightCommand, DeltaAction action, int brightnessDelta) where T : IUpdateDimmingDelta
public static T SetBrightness<T>(this T lightCommand, int brightness) where T : IUpdateDimming
As I can't create a new branch / pull request, please see code below. Would be great if you could incorporate this in the next release.
Add new interfaces:
namespace HueApi.Models.Requests.Interface
{
  public interface IUpdateDimming
  {
    public Dimming? Dimming { get; set; }
  }
}

namespace HueApi.Models.Requests.Interface
{
  public interface IUpdateDimmingDelta
  {
    public DimmingDelta? DimmingDelta { get; set; }
  }
}

Have UpdateLight() implement new interfaces:
public class UpdateLight : BaseResourceRequest, IUpdateColor, IUpdateColorTemperature, IUpdateOn, IUpdateDimmingDelta, IUpdateDimming
{
....
}

Add to UpdateLightExtensions.cs:

    /// <summary>
    /// Helper to create DimmingDelta command
    /// </summary>
    /// <param name="lightCommand"></param>
    /// <param name="action"></param>
    /// <param name="brightnessDelta"></param>
    /// <returns></returns>
    /// <exception cref="ArgumentNullException"></exception>
    /// <exception cref="ArgumentOutOfRangeException"></exception>
    public static T SetBrightnessDelta<T>(this T lightCommand, DeltaAction action, int brightnessDelta) where T : IUpdateDimmingDelta
    {
      if (lightCommand == null)
        throw new ArgumentNullException(nameof(lightCommand));

      if (!(1 <= brightnessDelta && brightnessDelta <= 100))
        throw new ArgumentOutOfRangeException(nameof(brightnessDelta),"Value must be between 1 and 100");

      lightCommand.DimmingDelta = new DimmingDelta
      {
        Action = action,
        BrightnessDelta = brightnessDelta
      };
      return lightCommand;
    }

    /// <summary>
    /// Helper to create Dimming command
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <param name="lightCommand"></param>
    /// <param name="brightness"></param>
    /// <returns></returns>
    /// <exception cref="ArgumentNullException"></exception>
    /// <exception cref="ArgumentOutOfRangeException"></exception>
    public static T SetBrightness<T>(this T lightCommand, int brightness) where T : IUpdateDimming
    {
      if (lightCommand == null)
        throw new ArgumentNullException(nameof(lightCommand));

      if (!(0 <= brightness && brightness <= 100))
        throw new ArgumentOutOfRangeException(nameof(brightness), "Value must be between 0 and 100");

      lightCommand.Dimming = new Dimming
      {
        Brightness = brightness
      };
      return lightCommand;
    }

Add Unittests to LightTests.cs:
    [TestMethod]
    public async Task SetBrightnessDeltaDown()
    {
      var all = await localHueClient.GetLightsAsync();
      var id = all.Data.First().Id;

      var req = new UpdateLight().SetBrightnessDelta(DeltaAction.down, 10);
      var result = await localHueClient.UpdateLightAsync(id, req);

      Assert.IsNotNull(result);
      Assert.IsFalse(result.HasErrors);

      Assert.IsTrue(result.Data.Count == 1);
      Assert.AreEqual(id, result.Data.First().Rid);
    }

    [TestMethod]
    public async Task SetBrightnessDeltaUp()
    {
      var all = await localHueClient.GetLightsAsync();
      var id = all.Data.First().Id;

      var req = new UpdateLight().SetBrightnessDelta(DeltaAction.up, 10);
      var result = await localHueClient.UpdateLightAsync(id, req);

      Assert.IsNotNull(result);
      Assert.IsFalse(result.HasErrors);

      Assert.IsTrue(result.Data.Count == 1);
      Assert.AreEqual(id, result.Data.First().Rid);
    }

    [TestMethod]
    public async Task SetBrightness()
    {
      var all = await localHueClient.GetLightsAsync();
      var id = all.Data.First().Id;

      var req = new UpdateLight().SetBrightness(50);
      var result = await localHueClient.UpdateLightAsync(id, req);

      Assert.IsNotNull(result);
      Assert.IsFalse(result.HasErrors);

      Assert.IsTrue(result.Data.Count == 1);
      Assert.AreEqual(id, result.Data.First().Rid);
    }

Kind regards
Alexander

Small addition:
By updating the class UpdateGroupedLight to implement the two new interfaces, the extensions should then also work.

Thanks for the contribution. I added the code to the project and it's released with version 0.10.0.
Next time, you can fork this project, then make the changes on your own fork and create a PR to this project.

Hi Michiel,
thanks for adding the code, much appreciated! Just tested with the new version and works as expected.
I did notice a small error in my code though :
Dimming.Brightness is of type double.
The method signature for public static T SetBrightness<T>(this T lightCommand, int brightness) where T : IUpdateDimming mistakenly takes an int for the brightness parameter. While this does not break, it might be worth fixing at some time. No need for an immediate fix. Sorry for the inconvenience!
I will definitely give forking a try for further enhancements!
Closing this issue as resolved.
Kind regards, Alexander


Injecting dependency into useFactory results in error.

Describe the bug
From version 5.1.5  (PR)
ImportingMikroOrm with forRootAsync and injecting any dependency in useFactory results in error.
Stack trace
TypeError: Cannot read properties of undefined (reading 'get')
    at Object.useFactory (/home/jdr/Workspace/xxx/src/api/core/core.module.ts:15:33)
    at Function.createEntityManager (/home/jdr/Workspace/xxx/node_modules/@mikro-orm/nestjs/mikro-orm-core.module.js:125:65)
    at Function.forRootAsync (/home/jdr/Workspace/xxx/node_modules/@mikro-orm/nestjs/mikro-orm-core.module.js:89:31)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

To Reproduce
Steps to reproduce the behavior:
Use MikroOrmModule.forRootAsync() and inject any dependency to useFactory.
@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    MikroOrmModule.forRootAsync({
      inject: [ConfigService],
      useFactory: async (configService) => {
        return {
          entities: [
            './dist/domain/**/model/*.js',
          ],
          dbName: configService.get('database.name'),
          type: 'postgresql',
          user: configService.get('database.user'),
          password: configService.get('database.password'),
          port: configService.get('database.port'),
          host: configService.get('database.host'),
          migrations: {
            path: __dirname + './dist/persistence/migrations',
            pattern: /^[\w-]+\d+\.js$/,
          },
        };
      },
    })
  ]
})

Expected behavior
You should be able to use async provider without any errors thrown.
Versions

Dependency
Version

node
16.13.2

typescript
4.9.4

mikro-orm
5.6.2

mikro-orm/nestjs
5.1.5

When I import ConfigModule (Without isGlobal) it works fine.
I have similar problem, I'm using forRootAsync with contextName: redshift, then I get an error when I  want to use MikroORMModule.forFeature
Error: Nest can't resolve dependencies of the InactiveCustomerEntityRepository_redshift (?). Please make sure that the argument redshift_EntityManager at index [0] is available in the MikroOrmModule context.

I kinda doubt this is something fixable from this package, its nest DI that is responsible for the injection.

But it's working just fine with prior versions

I've linked PR that breaks it

Just look at what the PR does, how come it would be connected to nest DI not injecting a dependency? If it is, it still sounds like a nestjs bug to me.

Could somebody provide a repository with this bug, not just the streets above but something I could just clone and start playing with, and I'll try to see if I can figure out what's up here?

This line seems suspicious to me. if someone sets up a useFactory in the async registration that has a value pissed to it, like the ConfigServive, but it's called directly without paying any necessary parameters, then an error like the one above would definitely be present

Can confirm that this issue arose for me after upgrading from 5.1.2 to 5.1.5. I've fallen back to 5.1.2 for now.

This line seems suspicious to me. if someone sets up a useFactory in the async registration that has a value pissed to it, like the ConfigServive, but it's called directly without paying any necessary parameters, then an error like the one above would definitely be present

Right, I moved this into try/catch block to get around but, but forgot it can be async as well.
Could you suggest a better way to let nest DI inject the dependencies? The idea behind those changes was to get resolve the same options as the ORM will get, and register the EM flavor based on the driver.

I think you could probably create the entity manager as a provider so that the options can be injected into a factory for it. Would require a bit of re-work, but I think I might be able to help with that this week? I'll have to clone the repo and see what can be done there

Both should work, the one from core as well as the driver-specific implementation. They should resolve to the same - during runtime, it will be always the driver-specific implementation, but it's valid to inject it based on the import from core too. So in a way, those are just aliases. In the next major, if we find a good way to do what 5.1.5 tries to do, I'd like to drop the "old way" in favor of it, this shouldn't be driven by what package is installed.

Also, is there anywhere you would prefer to have brief conversation about the code other than this issue? I'm fine with here if that's your preference just want to make sure

It's fine here, or feel free to join the slack channel, I am there most of the time. I can do discord as well, but I don't keep that app open most of the time (unlike slack).

If you pass contextname in the root (at the same level with useFactory), it works for me.

I did a quick and dirty hotfix by awaiting the useFactory, which should fix the try/catch block. Keeping this open till we find a proper way.
Available in v5.1.6

Closing as resolved via #166, will be part of v5.2.4


Forbid wildcard dependencies on crates.io

Rendered

:+1:
I warn people not to do so with hyper, but it still happens, and I break
lots of people when releasing new breaking versions.
On Thu, Aug 6, 2015, 10:12 PM Steven Fackler<EMAIL_ADDRESS>wrote:

You can view, comment on, or merge this pull request online at:
https://github.com/rust-lang/rfcs/pull/1241
Commit Summary

Forbid wildcard dependencies on crates.io

File Changes

A text/0000-no-wildcard-deps.md
https://github.com/rust-lang/rfcs/pull/1241/files#diff-0 (113)

Patch Links:

https://github.com/rust-lang/rfcs/pull/1241.patch
https://github.com/rust-lang/rfcs/pull/1241.diff

—
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/rfcs/pull/1241.

An alternative is to continue allowing wildcard bounds, but recruit a team of trusted users to tighten the bounds if any breakage comes up.
Another thing to consider is an --allow-newer option, which tells Cargo to ignore upper bounds during dependency resolution. This is useful when you know a crate will build against a newer dependency, but the maintainer hasn't updated it yet.
Both solutions are used by the Haskell community, which has grappled with dependency issues for quite some time.

Definitely +10000 for post-hoc changing of the constraints. I'd also love it for users to suggest changes to the constraints, and a flag for cargo to go by the user consensus instead of the official constraints (consider abandoned libraries)
This is still useful if we decide its better to start conservative and then relax constraints.

Changing dependency constraints for published crates seems like it would wreak havoc on build reproducibility. We could perhaps add a fourth "level" that could only be incremented on the crates.io side, so version 3.2.4's dependencies could be corrected in version <IP_ADDRESS>.

Well definitely log changes.
I suppose one depend on a specific subsets of that "fourth level" but I'd wait to see if reproducibility is a problem in practice. I guess my initial impression is that the change is supposed to be unobservable, but I haven't thought that through.

Hmm, I think I might have been thinking about that wrong and reproducibility wouldn't be an issue.

Crazy idea: disallow wildcard dependencies, but allow lower bounds. In that case, when a dependency is updated to a new major version, automatically build and test with the updated dependency. If the build, or any of the tests fail, automatically insert the correct upper bound.
Realistically, that's all the crate maintainer is going to do anyway, so may as well automate it!

I'm in favor of this RFC, the motivation is quite right in that not having an upper bound on a version constraint is basically guaranteed to break at some point in the future.

@lfairy

An alternative is to continue allowing wildcard bounds, but let maintainers tighten the bounds post-hoc if any breakage comes up.

I agree with @sfackler that this is not a great idea for reproducibility. A lock file indicates a solution to the dependency graph provided by the set of Cargo.toml files in play, but this only works because the constraints in place by the dependency graph are constant. If they were allowed to change over time (e.g. the bounds are changed) then previously generated lockfiles which represented a solution will no longer be a valid solution.
It could in theory be possible to track revisions and then you lock to a particular index file at a particular point in time, but that seems much more complicated than just rejecting * dependencies which, as @sfackler pointed out, are basically guaranteed to break in the future.

@Diggsey

Crazy idea: disallow wildcard dependencies, but allow lower bounds. In that case, when a dependency is updated to a new major version, automatically build and test with the updated dependency. If the build, or any of the tests fail, automatically insert the correct upper bound.

Unfortunately I don't think this can be done in a bulletproof fashion. Your dependencies can become part of your own public API if you just export or return one of the types, so an upgrade across the major version of a dependency may not break you but could break your own downstream clients. It generally seems like the best practice is no matter what still "have an upper bound".
If you really want to keep the current behavior then dependencies can look like:
foo = ">= 0.0, <= 10000"

(or something like that)

I wish to solve this too, the way "*" is used as default now is worrying.
I imagine a few crates actually want the convenience of "*", if they are constantly changing. For example crates tracking nightly, syntax extensions could be in this position.

If you really want to keep the current behavior then dependencies can look like:

I was specifically interested in avoiding the time pressure: when an upstream crate upgrades to a new major version, it basically has a domino effect, where all downstream crates have to update as quickly as possible, as soon as all their dependencies are updated to use the new version. Invariably, there's one crate whose maintainer is on holiday or busy or whatever, which results in the entire ecosystem being held back.
On the other hand, allowing upper bounds to get ahead of the actual versions of crates seems to defeat the point of removing wildcard support: if you can continue to use "<= 1000" then for all intents and purposes, it's a wildcard bound.
While automated upgrades as I described would only be as good as the tests, there's nothing to say that their maintainers do more than just rerun their test suite with the new version anyway.
Another option would be to allow upper bounds to only go say one or two major versions ahead of the actual published crate. With a little help from cargo, that could be quite powerful (eg. an easy way for the maintainer to switch from using the latest published version of a crate, to one tagged 'beta' in the associated git repo, would allow them to also test one version ahead, and allow everyone to update their crates in parallel ready for when one of their upstream crates has a new major version)

While I'm mostly for this RFC, I'm concerned about the point @bluss brings up that there may be some legitimate uses for wildcard dependencies. Maybe there could be some opt-in way to allow wildcard dependencies, which would discourage the majority of people from enabling it unless it was really needed? Or maybe if this is something only unstable projects need, we could allow this for projects with a major revision number of zero (I don't know if this actually means unstable in semver, but it's how I use it)?

Super unstable projects are not really served well by crates.io's current setup - you end up with tons of versions that live in S3 forever wasting space.
Maven has SNAPSHOT versions in addition to normal release versions, which differ from normal release versions in that they're mutable. The dependency is simply overwritten every time it's updated.

Could "super unstable projects" just be depended on via a git dependency?
[dependencies.super_unstable]
git = "https://githuib.com/super/unstable"

Yeah, that is definitely the other alternative, and now that I think about it, seems like a better method than SNAPSHOT publishes given that Cargo has built in git support.

I'm not really a fan of this. Most of the time, my code is fine with newer versions of other crates. Forbidding wildcards just means that I'll try to work around it (by trying to set very high max versions) or just have to spend more time needlessly bumping versions in my Cargo.toml files, pushing new versions to git, and publishing a new version on crates.io. We'll be trading an occasional need to fix things with an ongoing desire to bump version numbers of dependencies.
Without some type of automation to handle updating Cargo.toml files like we have for Cargo.lock files, I think this is definitely a bad idea. Even with that automation, I'm concerned this will result in more things than necessary being linked into projects (more than 1 version of a crate) even in cases where 1 version of a crate would work.

"Most of the time" isn't really good enough if your constraint choices end up breaking random downstream users.

@jmesmon very likely scenario: your crate foo depends on crate zed with a * version. zed releases version 2.0 with breaking changes the same time you're on vacation. All users of your crate suddenly find that they are downloading<EMAIL_ADDRESS>and their project is no longer compiling.
Worse still, what if you no longer care about crate foo. You've moved on to better, green crates. So you don't pay attention to when it suddenly cannot build anymore. Users scramble trying to figure out how to do so.

Compare to you depending on zed = "1.0", which will accept ALL versions of 1.x. Users will automatically get minor and patch releases, such as 1.7.89. Assuming zed follows semver, everyone is happy.

I just realized one reason I use wildcards in a lot of my projects is I don't want to bother looking up the version number of the project. I often know the name of the crate, but don't know the version off the top of my head. I'd be much more willing to ditch wildcard dependencies if I could ask Cargo to add a dependency, and Cargo would add a reasonable default version (maybe only the major and minor version numbers, i.e. 1.0) or maybe the default could be configured. There are some package managers that have this functionality (i.e. bower install jquery --save), having this in Cargo might help here.

As convenient as it would be, I think it is hypocritical to allow "git dependencies" but not wildcards. Both offer the same impossible promise that some library will never make a breaking change to it's interface. If we need one, I suggest we allow both, but banish package (releases) that use them to some "unsafe sublisting" of packages.
@alexcrichton Revising the bounds is done because it is impossible to get the bounds both sound and complete---because upstream revisions that haven't been made yet. I am OK with shrinking the bound to make it sound being a patch version bump---since one can rely on bugs in the code, one can rely on bugs produced by an unsound bound that nevertheless results in a successful build. But extending the bound (in attempt to make it complete) is always a harmless change---even when the bound is extended unsoundly---since lock files ensure reproducible builds.
This reminds me, does cargo attempt to avoid earlier patch versions? Since the only reason to publish a new patch version is a performance increase or bug fix, it seems between foolish and dangerous to accept earlier patch versions---don't want to get downstream "accustomed" to an upstream bug, especially one that has been fixed. By contrast, a bump in the minor version may just indicate an extended interface, in which case there is there no harm whatsoever in using the older version.

@gsingh93 Cargo will still support "*", so you can use that during initial development. Then just write in the versions you used before publishing?

@Ericson2314 git dependencies are already forbidden on crates.io. Nothing in here proposes to change that.
I tentatively think that loosening constraints after publish would be a reasonable thing to do, but that seems out of scope for this RFC.

@seanmonstar @sfackler Isn't using/shipping a Cargo.lock file supposed to prevent some of the issues you're concerned about?
Right now downstream crates can avoid bumping the versions by controlling their Cargo.lock file a bit more directly.
Perhaps an alternate that doesn't increase the burden of maintaining crates would be to provide tools that allow more fine grained control of Cargo.lock?

A crate is published once but depended on literally thousands of times. I am more than happy to impose a small cost on the publish side to minimize costs on the consuming side.

Huge :+1:, this will help a lot to prevent crates.io from falling into the kind of transitive dependency hell situation other package repositories have been plagued with.
As a general principle, I think crates.io should strive provide these "invariants":

The dep and transitive deps will always exist (achieved by disallowing non-crates.io deps)
The dep and transitive deps will be unambiguously licensed (achieved by requiring a valid license field)
IFF the dep and transitive deps follow the semver standard, stable deps will always compile on the stable branch version ^[the most recent stable branch].

This goes partway toward achieving the last one, though it would further require a few "additional standards" to be applied to crates marked 1.0.0 or greater, specifically that:

They compile on the most recent stable Rust.
All of their dependencies and transitive dependencies are 1.0.0 or greater.

This RFC is now entering its week-long final comment period

I'd just like to mention that if this lands I will have to modify the dependencies of 420 crates.

@retep998 this should be trivial to script a replacement, e.g. replace "*" with ">= 0.0, <= 10000" as @alexcrichton suggests above if you wish to continue using the suboptimal version spec.

This RFC also doesn't propose to do anything to existing versions that have already been updated. You'll need to adjust the constraints the next time you release one of those 420 (!) crates, but presumably be touching the source anyway.

I'm very against this proposal.
My experience with this issue that lead to me being in favor of upper-boundless dependencies was in maintaining Lita, a chat bot for Ruby similar to GitHub's Hubot, where users write their own plugins which are published to the central RubyGems server (rubygems.org) as gems. rubygems.org and "gems" are equivalent to crates.io and crates in the Rust world, respectively.
One of Lita's features is the ability to generate a skeleton gem with all of the necessary files to quickly publish it as a plugin to rubygems.org. This is roughly equivalent to the cargo new command. Initially, the generated plugins were locked to the major version of Lita that generated them. For example, if I used Lita 2.1 to generate a plugin, the gemspec file (equivalent to Cargo.toml) would depend on Lita ~> 2.1. That is, 2.1.x as the minimum, and anything in the 2.x.x series, disallowing 3.0.0 and higher.
When I released Lita 3.0, I took great care to make sure that the new version did not break existing plugins published to rubygems.org, because I wanted end users to be able to upgrade Lita itself without waiting for all the maintainers of the plugins they used to upgrade their plugins to be compatible. Unfortunately, all the plugins that had used the generated gemspec were locked to the old version of Lita, so even though they would have worked, every single published plugin had to be updated by its author, which was not well received, and deservedly so.
Recall that in Semantic Versioning, a major version change is required for breaking changes, but it doesn't mean that breaking changes are required. It's possible if not probable that specific breaking changes don't actually affect many programs that depend on the library because they don't happen to use the code paths that changed.
In Lita, I follow an approach where major version changes involve two things:

Deprecations of APIs that will be removed in the next major version.
Removal of APIs that were deprecated in the last major version.

This has the following effects for plugin authors, assuming their plugin has no upper bound on its Lita dependency:

If their plugin does not use any of the APIs newly deprecated, they don't have to do anything at all. Their plugin continues to work as it always did.
If their plugin uses deprecated APIs, it still continues to work for now, and they have an entire major release cycle in which to migrate their plugin to use new, future-compatible APIs.

If the dependency on Lita were locked to a major version instead, they would always have to update their plugin just to change the version dependency, even if no code changes were required. This in turn would result in every user of Lita needing to update the version of each plugin they use. Some of these plugins may not even be maintained anymore, and end users are then forced to fork the original code to make the trivial version dependency change just to keep running it otherwise unaltered. Very frustrating churn for everyone involved.
Yes, it's possible that a future update to a dependent library will break your project. But it is not a guarantee, and the nature of software is to move forward. If a library intends to stay active and engaged with its community, I'd argue it is the responsibility of its maintainers to update it when breaking changes in its dependencies actually happen in a way that affects it. Disallowing upper bounds doesn't prevent that update from being necessary when the dependencies do break. That will happen either way. But it does force both users and library authors to do essentially pointless work in the most common case.

@jimmycuadra One way to solve your specific problem is to use a version bound of >= 0.0, <= 10000.

If a library intends to stay active and engaged with its community, I'd argue it is the responsibility of its maintainers to update it when breaking changes in its dependencies actually happen in a way that affects it.

Agreed. But in the mean time, let's not break the builds for everyone else needlessly.

@BurntSushi if everyone can just switch to using >= 0.0, <= 10000, I don't see a point in banning *.
Is our goal just to make people type more? Will we forbid >= 0.0, <= 10000 in the future and force a second migration to some other alternative?

The goal is to have users pin versions like  "x." or "0.y." , in a way that avoids breaking upgrades, as far as possible.

@jmesmon I believe the idea is that the majority of libraries on crates.io will, in fact, have breaking changes on new major versions.
If someone is determined to allow their library to break on new versions of other libraries, they are still free to do that, with extra work. However, this RFC will require everyone which is using * to re-evaluate their decision at the very least, and if they are completely sure that they want their library to break they are still free to use >= 0.0 <= 10000. However, I believe the majority of people using * are pretty much just being lazy about dependency management, and don't actually want to have their library fail to build in the future.
In your specific case, * doesn't seem like the best idea either. * is the easiest solution, but I think >=2.0 < 4.0 would probably be better, since two major versions = breaking changes.

@daboross my point is that we're just making >= 0.0 <= 10000 into the new "easiest solution"

@jmesmon >= 0.0 <= 10000 is definitely explicitly a "hack" construct though. I mean * could definitely look idiomatic, while >= 0.0 <= 10000 makes it very explicit that this is what you are intending to do, and that it wasn't intended for you to do it.

You shouldn't have to use a hack for what is a completely valid use case. FWIW, in the Ruby ecosystem, if you have open-ended dependecies, you get a warning to stderr when building the package, but it is not rejected outright by rubygems.org. I still think it's not the package manager's business to have an opinion about this, but a warning is a lot better than what is being proposed in this RFC.

Perhaps you should need to pass a force flag of some sort in order to cargo publish when you have a "*" dependency?

I still think it's not the package manager's business to have an opinion about this

It won't. This is a restriction put on crates.io.

If we do care about soundness, make it so constraints can only refer to versions that are already published.

It won't. This is a restriction put on crates.io.

Exactly. It's useful to remember this only affects publishing to crates.io. Any other registry can have it's own opinion, and you can also happily use * locally.

Sorry, I used the wrong term there. I was referring to crates.io. I don't think it is Cargo or crates.io's business to have an opinion about this.

@jimmycuadra

In Lita, I follow an approach where major version changes involve two things:

Deprecations of APIs that will be removed in the next major version.
Removal of APIs that were deprecated in the last major version.

That is certainly a excellent way to manage a library! Cargo's version constraint support allows developers to take care of that sort of strategy without needing to resort to wildcard constraints. If I'm working on a library that depends on Lita 2, the most recent version, then the conservative approach is to add a constraint of ^2.0.0, as you mentioned. However, if I'm sure that I'm not using any deprecated functionality (and I trust that only deprecated functionality will break in the next release), I can then adjust my constraints out to >= 2.0.0, < 4.0.0, allowing the library to be used with both version 2 and version 3. When version 3 comes out, I have an entire release cycle to figure out if I need to remove deprecated functionality and adjust the version constraints as appropriate.

But it is not a guarantee, and the nature of software is to move forward. If a library intends to stay active and engaged with its community, I'd argue it is the responsibility of its maintainers to update it when breaking changes in its dependencies actually happen in a way that affects it.

It would be fantastic for authors to always update their libraries immediately when something happens to break them, but things don't always work out that way. Maybe the author is on vacation for a month and isn't checking his or her email. Maybe the library's simply been abandoned (this is not at all uncommon in ecosystems with a long history like Java's. For example, Trove is a fairly popular library that hasn't seen an update since 2012 and is very much not feature complete). In both cases, users are stuck doing painful hackery to "recover" from a cargo update.
Things can go really wrong if you don't have any constraints on what versions of dependencies you pull in, and your users will not be happy to have to go spelunking through transitive dependencies to figure out which library they have to force back to what version.
Even if you keep your library up to date such that future releases of your dependencies don't break you, a wildcard version means your library supports all past versions as well, which is almost certainly not the case. To me, a wildcard constraint just means "versioning is hard, I give up".
It's also not a fundamentally terrible thing for libraries to not use the most recent bleeding edge version of a library (speaking as someone who has burnt days to searching through the source versions of Jackson and Dropwizard to track down bugs introduced in a new release, staying off the bleeding edge is sometimes preferable). If a library depends on an old version of another and nobody cares, does it matter? I maintain a decent number of crates.io packages, all of which have bounded version constraints. Over the last year or so of crates.io being a thing, I think I've been asked twice or maybe three times to expand a constraint. With those requested bumps and bumps that I've done manually to pick up new features, I'd say that the new version did break things for my library maybe 50% of the time.

Sorry, I used the wrong term there. I was referring to crates.io. I don't think it is Cargo or crates.io's business to have an opinion about this.

crates.io does have a responsibility to make sure the ecosystem of crates uploaded to it has some sense of reasonableness in my opinion. It doesn't allow crates to be hard deleted (except in extreme circumstances) so that users can be relatively confident that they'll be able to build their code indefinitely. It requires a license because using an unlicensed library is often totally impossible. It requires a description so users have some idea of what the thing is and if it might fit their use case. We would add this new restriction because it would give users the confidence that the libraries they depend on will compile, and continue to compile over time.
@BurntSushi
I wouldn't encourage the use of things like > 1, < 100000. If those kinds of constraints start popping up, we're really no better off than before and there will probably be a follow up RFC to deal with that.
@Ericson2314
I'm a little hesitant to be that strict up front - there are use cases like @jimmycuadra's where you'd want to be able to look a little bit into the future. It might make sense to allow constraints to refer to the next unreleased version, but no further though.
@retep998
That's certainly an alternative, though I would personally push for something that's a bit more "in your face" than a simple "--force" flag or something like that.

Good points, @sfackler. I definitely wasn't advocating for the "*" wildcard – I'm only concerned with forcing an upper bound. I think there are some trade offs here, both positive and negative effects for the main library author and the plugin authors (continuing my Lita example.) Let me see if I can enumerate them, partially for my own clarity of thought:
The columns here represent two options for crates.io's behavior as we are discussing. The rows represent the role of the crate (or application in the case of the end user), and the time, effort, attention, and responsiveness of their respective authors.
| No upper bounds (current) | Upper bounds (proposed)
--- | --- | ---
Library author | If any plugins or end users have direct dependencies on some of the same crates the main library also depends on, they are free to use the newest version without having to wait for an update for the library. The newest version of the shared dependency may break the main library in some way, but will be apparent immediately if it causes the plugin to stop working. The library author does not need to continuously release new versions of the library every time a new version of one of its dependencies is released. | Plugin authors are bound to the versions of any shared dependencies required by the main library. If they want to use a newer one, they must either wait for an update to the main library that relaxes the version constraint on the shared dependency in question, or contact the author directly to nudge them to do it. If the shared dependency's new version includes fixes for any security issues, the plugin is blocked on addressing these issues until the main library allows it to by relaxing the version constraint.
Plugin author | Updates to the library may cause the currently published version of the plugin to break. This is the situation this RFC is trying to prevent. However, if the library never makes changes that would break the plugin, the plugin will continue to work for end users even if the author stops maintaining it. This is a very valuable property with a large ecosystem of plugins. | Updates to the library always require an update to the plugin in order for end users to use the latest version of the library. If there were breaking changes, code must be changed, otherwise only the version requirements must change. There is no danger of the current published crate breaking at any time, which is a valuable guarantee for crates hosted on crates.io.
End user | When a new version of the main library is released, it's a drop-in upgrade as long as the plugins they use continue to work. However, some plugins might break. If this happens, the user must either wait for the plugin author to issue a new version, or contact the author directly about the problem. If the author no longer maintains the plugin or is otherwise unresponsive, the user must either stop using the plugin or maintain their own fork and fix the issue themselves. The end user's program also exhibits the same relationship to its upstream dependencies as the plugin does to the main library, in that it can use the latest version of any shared dependencies without requiring a change to any of the upstream libraries. | When the main library is updated, all plugins will now be unusable until they are each updated as well. If the maintainer of a plugin is unresponsive, the user will either have to stop using the plugin (which may have continued to work just fine without the upper version constraint) or fork, fix, and maintain a version of the plugin themselves.
Overall, I think the trade off boils down to which is more important at the expense of the other: a crate that will always compile, or increased churn for all programmers all the way down through the ecosystem of a project, whether or not real changes are needed.
I do see the value of both, but again, I think it's a subtle enough issue that as a library maintainer I should be able to make the choice for myself and still enjoy the benefits of having my crate hosted on crates.io.

I'd also like to quote @Diggsey from much earlier in this discussion, as he articulated some of my concerns with this proposal quite well:

I was specifically interested in avoiding the time pressure: when an upstream crate upgrades to a new major version, it basically has a domino effect, where all downstream crates have to update as quickly as possible, as soon as all their dependencies are updated to use the new version. Invariably, there's one crate whose maintainer is on holiday or busy or whatever, which results in the entire ecosystem being held back.

On the other hand, allowing upper bounds to get ahead of the actual versions of crates seems to defeat the point of removing wildcard support: if you can continue to use "<= 1000" then for all intents and purposes, it's a wildcard bound.

It might make sense to allow constraints to refer to the next unreleased version, but no further though.

These properties preserve soundness iff the bound is sound at publication time, provided upstream does not break semver:

The starting version in a range should always be published
The end version in a range must either

be published
be an exclusive bound on the next unpublished major.

These properties disallow constraints assuming upstream will violate Semver in the future (but allow for violations that already occurred)

The end version may be a major release
The end version may be a minor or patch release bound is exclusive and it is published

These two lists combine.

@jimmycuadra
This is related to my soundness completeness thoughts earlier. Soundness is no bad builds, completeness is maximally (i.e. without breaking soundness) relaxed version constraints. With most phenomena baring these names, soundness is more important, but I agree it's less clear here since failing builds are easier to diagnosis than over-tight constraints.
But consider these two things:

The churn would a big problem but for allowing package maintainers to retroactively fix mistakes. Then only immediate consumer need to be edited, rather than also transitive consumers.
We've talked about automatically comparing interfaces to guard against obvious breakage. That same infrastructure could propose constraint relaxations.

These lead me to believe we might as well go for soundness cause we can, and the churn fallout can be ameliorated now, and moreso in the future when the growth of crates.io would make it worse.
Also, regardless of the severity of the churn issues, this is an issue that affects library consumers more than producers, so IMO library maintainers morally don't "deserve" more discretion on the matter.

Also, regardless of the severity of the churn issues, this is an issue that affects library consumers more than producers, so IMO library maintainers morally don't "deserve" more discretion on the matter.

Perhaps what you're saying here still applies to my case, but my primary motivation is not to make my job easier, it's to keep the plugin authors (the middle of a three-tier hierarchy) from having to make updates to otherwise working software in order for the end users (the bottom tier) to continue using the plugins as the main library evolves.

I don't think allowing 0 < 12456789.0.0 is the same as allowing * because * is the easiest semantic versioning requirement to use; it seems to me like the obvious default for as long as you are the only one building your crate (i.e. when your crate is not on crates.io). Typing out a ridiculous version bound is much more explicitly disregarding versioning reliability, and is much more of an act that the library author has to decide to do. I don't have a strong opinion about whether or not to allow fictionally large upper bounds, but I don't think allowing that makes disallowing * pointless.
@jimmycuadra there is a big difference between not being able to use the newest version of a library and not being able to use it at all. It seems much less onorous to me to have to wait on your dependencies to be able to upgrade to a breaking new version of a library than to have a situation where your build is non-functional because one of your dependencies is making false statements about its transitive dependency versioning requirements.

All of this discussion also assumes that SemVer is actually something you can rely on, which you most certainly cannot. People make breaking changes in minor and patch releases all the time, sometimes intentionally because they don't follow SemVer, or unintentionally because of a bug or because it's just really difficult to tell if you're breaking backwards compatibility in some way. Even with upper bounds enforced, there's no guarantee that a crate that built at one point will build again unless you lock every dependency down through the chain to an exact version number.

@jimmycuadra I don't see where that assumption is made. I don't think anyone is under the illusion that there is some iron clad guarantee of non-breakage in the absence of a tool that can automatically check semantic versioning for you. This is about doing what we can to mitigate breaking changes. A worthy cause, IMO!

I would be much happier with this if I could override the version constraints of transitive dependencies in my projects. Relying on upstream to bump their dependency versions sounds very annoying, and will lead to perfectly usable crates being forked repeatedly just so that people can bump the dependencies.

All of this discussion also assumes that SemVer is actually something you can rely on, which you most certainly cannot. People make breaking changes in minor and patch releases all the time, sometimes intentionally because they don't follow SemVer, or unintentionally because of a bug or because it's just really difficult to tell if you're breaking backwards compatibility in some way. Even with upper bounds enforced, there's no guarantee that a crate that built at one point will build again unless you lock every dependency down through the chain to an exact version number.

I totally agree here. Unless a library explicitly specifies a specific version of a dependency there is no way a library author can make any guarantee that their code will work with all later minor/patch versions of the dependency.
It seems odd to me to suggest that library authors not pin versions of dependencies - presumably so that multiple crates depending on the same crate are more likely to be compatible - and yet suggest we force specifying an upper bound. Specifying an upper bound does not guarantee that the library is going to work with all versions anyway, so this seems like a) an arbitrary line in the sand and b) that this is a more generic problem.

FWIW, I (alas) spend most of my days working in python. The vast majority of my dependencies (and in other projects) don't specify an upper bound unless its known to break at a specific version. This has yet to cause much of an issue.
My understanding is that not specifying an upper bound is the recommended practice in most package systems, so I would be very interested to hear peoples experiences in these.

This seems like a more generic problem: how do you deal with dependencies that break with newer/particular versions of specific libraries? (These could be API changes in major version bumps, accidental API changes in minor versions, bugs, etc.)
Forcing an upper bound is going to be a pain in the long run if you can't override the version constraints of dependencies. Especially in the presence of unmaintained, but still usable, libraries.
These problems are going to be especially noticeable now since we have a higher ratio of new unstable libraries vs old stable libraries.

@erikjohnston

It seems odd to me to suggest that library authors not pin versions of dependencies - presumably so that multiple crates depending on the same crate are more likely to be compatible - and yet suggest we force specifying an upper bound. Specifying an upper bound does not guarantee that the library is going to work with all versions anyway, so this seems like a) an arbitrary line in the sand and b) that this is a more generic problem.

It's not about guarantees - it's about finding a middle ground between being completely inflexible to the point of too-frequent breakage in dependency resolution and being completely flexible to the point of too-frequent breakage in compilation. Semver is the norm for crates.io packages - if an author breaks back-compat within the same major version, you can expect that people will be filing bugs on the project to get the release yanked, but there's no such norm for major version bumps.
The appropriate constraint depends on the dependency. For a library whose author provides strong guarantees about breaking change patterns, you can extend your version constraints much further than you'd be able to for a library with no such guarantees.

Thanks for the comments, everyone! I still feel that unbounded-from-above dependencies are a bit sketchy, but there are clearly compelling arguments that they work out in practice. How about we adjust the RFC to prohibit only true wildcard (*) dependencies. This will make library authors think to at least some degree about what versions of things they need and see how that goes. If we see the need to go further in the future, we'll probably want to pair the restriction with the addition of some tools to help with it, such as the ability to loosen constraints of published crates and the ability to force versions out of their constraint bounds on the consumer side.

@sfackler Limiting the proposal like that might build support now, but also just begs for a followup RFC, by which point more crates in violation could be published. What's wrong with adding all the restrictions we want (we can relax them later), along with something to ameliorate the concern about about churn?

In the current version the build can break if someone uses "*" you update your dependencies. This is clearly a bad thing. You can work around this by specifying a working version in your Cargo.lock.
In the proposed version, the upgrade of a library can be blocked by any crate in your dependency tree. This is also bad and cannot be worked around currently, so I don't think this RFC should be accepted until it addresses this, currently it just trades one issue for another, where the former has a work-around and the latter does not.

@tbu- I'm not sure how this RFC trades one issue for another. Even today, if a crate has an overly strict version bound, then you'll have the problem you described. This RFC does nothing to change that.

@BurntSushi Well, it pushes people away from the "*" problem which has a work-around to stricter version bounds which don't have a work-around currently. Once there is a way to get around a crate's overly restrictive bounds, this RFC will pose no problem.

@tbu- I don't really think Cargo.lock is really a workaround, due to the fact that this RFC would only affect libraries on crates.io, and it's currently idiomatic to not commit Cargo.lock to a version repository at all for library crates.
I mean, * will still work in binary crates and local crates regardless of whether this RFC happens or not, and - idiomatically - Cargo.lock is only used in those two scenarios (binary crates and local crates).

@daboross It's a work around in the way that that root node of the dependency tree can decide about all library's version, including library's dependencies. Cargo.lock used by binary crates also works for the library crates that the binary crate transitively depends on.
But as you say, all libraries would have to rely on the binary crate actually using them maintains a proper Cargo.lock, which isn't a nice thing either... I mean I really like this RFC, but we don't have override mechanisms for cases in which an author is not available. (As another example of this: Firefox regulary updates. Firefox addons usually include the next version as compatible as well, just because the author can't immediately release the next version when the next Firefox comes out. Firefox does come with an override tool (Compatiblity Reporter), so it's not that bad if you know about that tool.)

The current situation is not great, but I see @tbu-'s point in that sloppy versions are a way to work around the upgrade churn issue.

cc @wycats

Updated to only block wildcard deps, and roll out with a warning only for one release cycle.

This libs team discussed this RFC today, and decided that we were in favor but in light of the recent change by @sfackler we're going to re-up this for another week-long FCP.

I appreciate the change, thank you!

I have no problems with this proposal now that it has been changed to target only wildcards.

I've been thinking about this a lot, and I have a few thoughts.
I'm in favor of forbidding wildcard dependencies, as the current draft of the RFC proposes.
Version ranges make me uneasy, because they make it much more likely that a resolved dependency graph will still fail to compile, which is something I would like to eventually rule out altogether. I am not suggesting any changes to the current draft of this RFC related to version ranges, but I'll explore this topic further.
Shared Types
The core tension here is about shared types. To give a concrete example, let's say that format-time and enriched-time both depend on a time crate.
// format-time
extern crate time;
pub fn format_time<T: time::Time>(time: T) -> String {
  // format the time
}

// enriched-time
extern crate time;

pub struct EnrichedTime { /* ... */ }
impl time::Time for EnrichedTime { /* ... */ }

If a parent crate depends on both format-time and enriched-time, and tries to pass an instance of EnrichedTime to format_time, they better both be talking about the same time crate.
Cargo's Coarse-Grained Solution
Today's Cargo attempts to address this issue coarsely:
First, Cargo will automatically coalesce dependencies within the same major version into a single shared dependency across the entire graph. This means that if format-time depends on time 1.6 and enriched-time depends on time 1.7, they will still see the identical time::Time trait.
Second, Cargo assumes compliance with semantic versioning to make this work. This assumption is fundamental: if Cargo was not allowed to assume that time 1.7 was compatible with time 1.6, format-time and enriched-time (and any other crate with a shared dependency on time) would be forced to coordinate version bumping.
Third, depending on a range of versions (time 1.x to time 3.x) means that you are depending on a subset of the types in that range that are compatible across those versions, but without any enforcement.
If you are sharing those types in your public interface, or passing instances of those types to other dependencies, this creates a "matrix" problem: the only way to be confident that your crate will compile for all downstream crates is to build your crate will all combinations of upstream versions.
Shared vs. Internal Dependencies
One of the weaknesses of the current model is that it doesn't distinguish between dependencies used purely internally, as part of your implementation and dependencies exposed as part of your public interface.
Internal-only dependencies have a much higher-tolerance for using version ranges to select a subset of a crate's types that are compatible across major versions, because the code with the internal-only dependency knows exactly how the type is being used.
For example, even if a particular method on time::Time has changed between 1.x and 2.x, if your code doesn't use it, it is still safe to depend on the 1.x to 2.x range.
In contrast, dependencies exposed as part of your public API by definition do not know all of the ways those types are being used by downstream crates. As a result, it can only use version ranges if all of the types exposed in their public interface are compatible across those versions.
The Role of Small Crates and Semantic Versioning
Instead of trying to teach all crate authors the above rules, which are devilishly hard to get right, Cargo has so far relied on relatively small crates and semantic versioning to allow crate authors to describe compatibility for a small cluster of types.
Instead of asking format-time and enriched-time to coordinate a version bump of the time dependency across every "tiny" version bump, they are required to coordinate version bumps across major versions only.
The fact that people want sometimes to express their dependencies as ranges implies two things to me:

There are times where a subset of all of the types in a crate are compatible across major versions, and a crate wants to depend on that subset.
People are often using a crate as an internal-only dependency, where they only have to worry about finding a compatible subset of functions, not entire types.

A Proposal
I think we can address this problem with a small improvement:
Add a new matrix-build command to Cargo, which will build your crate against all combinations of (major versions of) upstream dependencies, so that you can figure out before publishing whether your version ranges are as compatible as you think they are.
Version Ranges Are Problematic
That said, I think that depending on version ranges for crates that you use as part of your public interface is a smell.
It assumes that there is a subset of a package's types and functions that are stable across major versions.
For example, if the time crate exposes both a relatively stable time::Time trait and more unstable utility methods, people may find themselves depending on the range of time versions that describe an implicit version of the time::Time trait.
If the time crates bumps its major version, all crates that depend on a range of time will need to check whether time::Time is still compatible, and bump the range. Of course, many crates in practice will forget to do this, meaning that perfectly compatible combinations of crates that share time::Time as a public dependency will no longer compile.
In this case, it behooves the author of the time crate to break out the more stable time::Time trait (time-traits and time-utils) and version it explicitly. This allows downstream dependencies that rely on time-traits to maintain compatibility with each other even when time-utils changes.
I see dependency ranges as an interim workaround, rather than a long-term solution.
Matrix Builds
We can reduce the risk of dependency hell caused by version ranges through cargo matrix-build. I'd like to make matrix-build a sanity check done by cargo publish (as cargo build is today), to ensure that combinations of upstream dependencies will compile downstream.
However, that can only work if dependency ranges are used as a last resort, and crate authors are encouraged to break out more stable interfaces from less stable implementation.
The simple advice amounts to:

If you're a crate that exports widely shared types or interfaces, you want to create a stable crate (in the same repository) that exposes just a set of stable traits that downstream dependencies can rely on.

This doesn't mean that everyone needs to preemptively create interface crates just in case. It just means that once a crate discovers that downstream crates are often depending on version ranges, the "right thing to do" is to break out the more stable interfaces from the less stable implementation. (if you're building a crate you intend to be widely shared, maybe you should do it preemptively.)

The library subteam discussed this RFC yesterday and the conclusion was to accept it, thanks again @sfackler!


telemetry check fix

We were still sending test telemetry for every CI run

Codecov Report

Merging #10771 (70bda14) into main (2a2309a) will increase coverage by 0%.
The diff coverage is n/a.

@@          Coverage Diff           @@
##            main   #10771   +/-   ##
======================================
  Coverage     63%      63%
======================================
  Files        476      476
  Lines      33039    33039
  Branches    5384     5384
======================================
+ Hits       20828    20837    +9
+ Misses     10201    10195    -6
+ Partials    2010     2007    -3

Impacted Files
Coverage Δ

src/platform/common/cancellation.ts
64% <0%> (-4%)
:arrow_down:

src/kernels/jupyter/jupyterKernelService.node.ts
79% <0%> (-2%)
:arrow_down:

...ommon/process/environmentActivationService.node.ts
71% <0%> (-1%)
:arrow_down:

src/platform/msrCrypto/msrCrypto.js
16% <0%> (+<1%)
:arrow_up:

src/kernels/kernel.base.ts
82% <0%> (+<1%)
:arrow_up:

src/kernels/helpers.ts
61% <0%> (+<1%)
:arrow_up:

src/standalone/api/kernelApi.ts
73% <0%> (+1%)
:arrow_up:

src/kernels/kernelDependencyService.node.ts
85% <0%> (+4%)
:arrow_up:


Create a project contextual default project id for GCP

If a user checkouts a project from GCP, by default all GCP actions should have that project pre-selected.

more broadly, maybe we just remember the last selected project and display it as pre-selected in the project selector.

good idea


Update implementation of AWSFile#copy_to to use S3Object#copy_to API

Reason

Better support for special characters

According to https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-keys.html, there are some characters, such as + (Plus), that are not necessary to be sanitized but requires special treatment.
We have encountered issues with filename containing + fails to copy correctly. S3Object#copy_to appears to handle this already if the target is a S3Object.

Utilizing the underlying S3Object's API with the same name seems to make more sense

Hope this makes sense and let me know what you think!

That was a small fix, very nice! Thanks 👍


Bookmarks broken on iOS, contentCFI always null

When creating a bookmark on iOS in a reflowable book, the contentCFI part of the bookmark structure returned by bookmarkCurrentPage is always null.
Digging a little deeper revealed that getCaretRangeFromPoint() always returns null.
https://github.com/readium/readium-shared-js/blob/develop/js/views/cfi_navigation_logic.js#L112

Looking into this but I might need some more info as to which books or the type of content that was tested.

@olivierkorner Does this problem occur with the EPUB you shared with Daniel Weck and I (Walter Bennet)?  Would it be OK for me to share that EPUB with Juan so he can look at this problem?  He will not distribute the EPUB.

@rkwright Yes it occurs with any reflowable EPUB I've tried.
of course, it's OK, you can share it with Juan, no problem.

This may be an issue with webkit. Looking for similar issues with getCaretRangeFromPoint, I found this:
https://bugs.chromium.org/p/chromium/issues/detail?id=263813
And indeed, I add "webkit-user-select: none" on  elements in my implementation.
Removing it seems to solve the issue.

Interesting find. The more I test the code that uses caretRangeFromPoint
the more I find that it's buggy and not 100% stable, which is fair it is
still experimental..
I'm going to start looking into an alternative or fallback method.
On Tue, Feb 23, 2016, 10:33 AM Olivier Körner<EMAIL_ADDRESS>wrote:

This may be an issue with webkit. Looking for similar issues with
getCaretRangeFromPoint, I found this:
https://bugs.chromium.org/p/chromium/issues/detail?id=263813
And indeed, I add "webkit-user-select: none" on elements in my
implementation.
Removing it seems to solve the issue.
—
Reply to this email directly or view it on GitHub
https://github.com/readium/readium-shared-js/issues/257#issuecomment-187831957
.

We are seeing this in NYPL as well.  The book consistently return a few paragraphs/lines prior to where the bookmark was placed

+1
@JCCR It appears that only the first page of each spine is able to be bookmarked.  I'm running the latest from develop.

Started work on an alternative method for improved IE11 support (maybe it might help iOS too). I'll double down on reproducing this on my end using iOS.

Confirmed that this is broken on iOS and Safari, but not Chrome/Firefox when user-select: none is used

@JCCR
Hey,  I'm working on a bookmark feature on iOS.  It's ok when calling openSpineItemElementCfi . After this I open the next page , the webView is totally blank. Do you have any idea why ?

Closing as stale


font changer

Description of the new feature / enhancement
please add tool to change windows font  ,thanks in advance
Scenario when this would be used?
please add tool to change windows font  ,thanks in advancefont changer
Supporting information
No response

Can you provide more detail. This is a bit vague on what the exact ask here. Providing maybe a few crisp examples with how someone would use this could be helpful.. /needinfo


Deliver - Non-Interactive Mode not working for initial setup

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I have read the Contribution Guidelines

Issue Description
So, I want to set up a folder that builds "deliver" areas for all of our app in the iTunes store so that we can easily edit metadata and use deliver's submit_build feature (which is awesome by the way thanks for that!) to submit the build for review automatically whilst at the same time pumping in updated metadata.
Firstly I need to create a folder for each of our apps dynamically, which I have done then using a bash script I move into the folder and want to run an initial deliver, in order to set up the folder and collect the metadata, screenshots and deliverFile (which we will then change).
HOWEVER the issue is the first input required by Deliver...
'No deliver configuration found in the current directory. Do you want to
setup deliver? (y/n)'

I need some way of simply answering 'y' to this from where the bash script calls the program.
After a search I found that you can pipe an input into it by using:
echo "y" | deliver ...

Which actually works when im copying and pasting the exact same command into the terminal, but as soon as its a bash script calling it, then I receive the usual error of:
`crash!': [!] Could not retrieve response as fastlane runs in non-interactive mode

Please tell me there is someway of forcing this input requirement to stop, I have also included --force true into the command parameters but this seems to only tame the "are the screenshots ok?" screen....
I suspect that there is an easy parameter I have missed on the net or this functionality simply isn't possible, so I may have been a little bit lacking in my explaination so please let me know if more details are needed...
Thanks in advance...
Complete output when running fastlane, including the stack trace and command used
outputfromFirstDeliver=$(echo 'y' | deliver --verbose --username 'OUR_LOGIN' --app_identifier 'OUR_APP_IDENT' --force true)

... ... ...
/Library/Ruby/Gems/2.0.0/gems/fastlane_core-0.44.1/lib/fastlane_core/ui/interface.rb:127:in `crash!': [!] Could not retrieve response as fastlane runs in non-interactive mode (FastlaneCore::Interface::FastlaneCrash)
	from /Library/Ruby/Gems/2.0.0/gems/fastlane_core-0.44.1/lib/fastlane_core/ui/implementations/shell.rb:114:in `verify_interactive!'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane_core-0.44.1/lib/fastlane_core/ui/implementations/shell.rb:92:in `confirm'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane_core-0.44.1/lib/fastlane_core/ui/ui.rb:14:in `method_missing'
	from /Library/Ruby/Gems/2.0.0/gems/deliver-1.11.3/lib/deliver/commands_generator.rb:41:in `block (2 levels) in run'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/command.rb:178:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/command.rb:178:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/command.rb:153:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/runner.rb:428:in `run_active_command'
	from /Library/Ruby/Gems/2.0.0/gems/fastlane_core-0.44.1/lib/fastlane_core/ui/fastlane_runner.rb:26:in `run!'
	from /Library/Ruby/Gems/2.0.0/gems/commander-4.3.5/lib/commander/delegates.rb:15:in `run!'
	from /Library/Ruby/Gems/2.0.0/gems/deliver-1.11.3/lib/deliver/commands_generator.rb:132:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/deliver-1.11.3/lib/deliver/commands_generator.rb:12:in `start'
	from /Library/Ruby/Gems/2.0.0/gems/deliver-1.11.3/bin/deliver:5:in `<top (required)>'
	from /usr/local/bin/deliver:23:in `load'
	from /usr/local/bin/deliver:23:in `<main>'

Configuration Files
This process doesn't rely on the fastFile or deliverFile as it is just the initial setup.
Environment
fastlane 1.90.0
deliver 1.11.3

Sorry that's currently not supported. You can always call the internal setup classes directly and write your own custom script 👍
Check out setup.rb inside the deliver folder for that


Update hlf url in readme

Update the url to hlf documentation in the readme as it is pointing to v.1.4 whereas v2.+ is now implemented.
I have used the latest version, but please let me know if it would be better to point towards any specific version

Nice catch !

Nice catch !