Clashes with pyenv

pyenv brings with it the python-build tool, which it uses to build python versions from source.
Now I've done pip install build, pyenv invokes this python-build, and breaks 😢
Maybe python-build could ship only for invoking as python -m build? This would have the advantage of always knowing which python binary you were invoking (the same reason pip recommends using python -m pip everywhere).
Or maybe pyenv could be convinced to change to pyenv-python-build or similar, though probably breaking some peoples' install scripts?

That's very unfortunate. We should probably move away from the python-build  branding anyway, since the PyPI package called that is something totally unrelated.
Still, we shouldn't eliminate the entry point. There are good reasons to use an entry point, see #3.
Maybe we can rename the entry point to something else like pybuild or build-package ? Might also be worth seeing if pyenv can be refactored to work without their python-build  being on the PATH. It won't help with anyone directly invoking their python-build , but maybe it will reduce the conflicts to a point that they are manageable.

Yes, I am open to suggestions, I am not sure what is the best way to proceed, I am open to suggestions.

pybuild

:shipit: 🚢

pybuild seems fine to me.
The name pybuild is taken on PyPI but seems abandoned with last release >4 years ago. Perhaps you can ask to take it over to point to this tool.
There are a number of tools on GitHub search called pybuild but none seem popular. Most prominently there's pybuilder, but I don't think that risks any confusion.

It builds distributions, right? What about a variation of_distbuild_, builddist?

"build" and "pybuild" are too generic to be meaningful to people who are not immersed in Python packaging; I think this should be called pyproject-build, and python-install, should it eventually be adopted, pyproject-install, on the basis that they have been introduced for the new pyproject format.

This somewhat relates to the discussion hapening in #42.
If we go with a generic name like build, I would the console script being called something like pypackage-build.

I'm kinda in favor of only shipping python -m build, mostly to keep the "CLI surface area" smaller.  It's easy to add in an entry point once we see widespread adoption. It's not easy to remove one though.

I am totally fine with that. The entrypoint only exists because @pganssle asked IIRC.

I also like just python -m build
@pganssle wrote

There are good reasons to use an entry point, see #3.

As far as I can see from the issue, there's only one issue - lack of support under pipx. It could be reasonable for pipx to add support for -m invocations, as I'm sure python-build wasn't the only tool without an entry point.

It could be reasonable for pipx to add support for -m invocations, as I'm sure python-build wasn't the only tool without an entry point.

This is not possible, because pipx needs to know under what name you want to expose the tool. If the tool does not provide a name, pipx cannot make up one. I'm in strong +1 that this tool needs to provide a console script name.

Okay, pipx is a strong enough reason for me to also be on board for adding an entry-point. I don't have any opinion on which one is picked / if pyenv is requested to rename stuff etc. :)

I have opened #117 which renames the entrypoint script to pyproject-build, which I think is a good name.
Let me know if any of you have issues with that name :blush:

@gaborbernat #117 hasn't merged yet -- so this isn't fixed yet.

Will the PyPI package be renamed as well or will people be instaling build to invoke pyproject-build?  If you're sticking with build, you should consider squatting pyproject-build on PyPI.

Yeah, I should create a  pyproject-build package that just depends on build.

I'm pretty sure that won't work with pipx - how are you going to re-expose the entry point?

Okay, so I'll put a setup.py there that will say something like this.
You were probably looking for 'build'! pyproject-build is a console script exposed by the 'build' project.

$ pip install build

What about just making pyproject-build depend via install_requires to build? (and re-expose the entry point for pipx reasons).

That would try to install two of the same entrypints. It might work in pipx, and maybe even in pip (haven't checked) but if I was implementing an installer frontend (which I kinda am :stuck_out_tongue:) I would probably throw an error or ask for user input and that's bad UX so I would like to avoid it.

Another option would be to just make a separate package pyproject-build that only exposes the entry point.
That might be marginally less confusing for people, since they can do pipx install pyproject-build to install the program pyproject-build, and they can do pip install build if they only want python -m build.

The difference between the project name and the entry point will confuse users regardless and I wonder if it wouldn't be better to relocate to 'pyproject-build' on PyPI - nip this in the bud before the package sees wider adoption.

The downside to this would be the way the version numbers would work. pyproject-build would probably effectively never need to change, so it could sit at one version forever while the relevant version number would be the one associated with build.

It would still suffer from not being upgradeable by pipx, unless you were to install 'build' (can you install packages without entry points in pipx?) then inject pyproject-build in the former's virtual env and expose the entry point, somehow.

The alternative would be always cutting releases at the same time just to bump the version number on pyproject-build, and have pyproject-build keep an == dependency on build.

Given the intended use case, I think this'll work best.

Let's just call the CLI tool build. 😈
takes off the hat that the devil gave him

At the moment I like best renaming the project as a whole to pyproject_build 🤔 And expose only that... And abandon build entirely, we haven't publicly/widely released yet, so might be the best.

At the moment I like best renaming the project as a whole to pyproject_build thinking And expose only that... And abandon build entirely, we haven't publicly/widely released yet, so might be the best.

This also sounds good to me. It is very hard to search for "build", "python build" or even "python-build". I originally didn't like pyproject_build or pyproject-build because I thought it implied that you must have a pyproject.toml file (even though this is very much not true), but if we're going to call modern (PEP 517/518) "pyproject" builds, it's definitely safe to say that this always does a "pyproject build".

It would still suffer from not being upgradeable by pipx, unless you were to install build (can you install packages without entry points in pipx?) then inject pyproject-build in the former's virtual env and expose the entry point, somehow.

Yeah, unless pipx has a way to say to update all dependencies even if the package version hasn't changed, that would be a problem. If we don't just rename the whole project to pyproject-build or pyproject_build, then I think the main reasonable option would be to have a "CLI-only" project on PyPI, with versions released in sync with build.
I do think it's not terribly unreasonable to have separate packages for the CLI tool and the library, IMO, since it would be nice for things built on top of the library to be able to depend on the version that has no associated CLI, but as with everything there are many usability trade-offs and no perfect solution.

The project is supposed to be a Python package builder. At this moment it exposes a PEP517 builder but if Python changes the build process in the future we will add support for that. So I think the project should keep the build name.
I think having pypyoject-build throw an error saying that the project is named build is a good solution. It does not cause a lot of user stress, people would just fix their pip/pipx install command.
At least that is my opinion, but understand if you don't feel the same.

The project is supposed to be a Python package builder. At this moment it exposes a PEP517 builder but if Python changes the build process in the future we will add support for that. So I think the project should keep the build name.

Do you envisage Python moving away from the pyproject format?  A lot of effort's gone into standardising, and standardising on, PEP 517 and 518 - the possibility that Python will migrate to a new format or standard, which would depart from pyproject so radically that it would no longer be appropriate to call it 'pyproject', is extremely remote and will remain so for many years to come.  That this tool would be adapted for the new format is an even bigger hypothetical.

You should never say never, but it's highly unlikely we'll move away from pyproject.toml anytime soon. If we need a new way of building we'll likely just change metadata in the pyproject.toml...

I can't count the times I have been hit by issues that originated years ago. When setuptools was created we also didn't know we would have to change things in the future. Software changes and so needs change, we simply can't predict the future. The entrypoint name can be easily changed, the project name can't. If pyproject-build doesn't make sense anymore we can create a new one and deprecate pyproject-build. I'd like to avoid telling users, pyproject-build is deprecated, you should now use this new tool.
The idea is, if things change in the backend, we will try our best to keep the frontend the same, avoiding breakage. I do not feel comfortable naming the project something as implementation/standard dependent as pyproject.
I still think the best approach would be to simply have the pyproject-build package tell users to install build instead, but I would accept pinning pyproject-build to the build version.

When setuptools was created we also didn't know we would have to change things in the future. Software changes and so needs change, we simply can't predict the future.

There's a reason this functionality is not part of setuptools. Similarly when things will change it most likely will be breaking enough that we'll need a new name, and can't just swap things under the hood.

The entrypoint name can be easily changed, the project name can't.

IMHO for not introducing more confusion along users it's prefered for the two to match. Which for me pushes into the direction to go with pyproject-build...

There's a reason this functionality is not part of setuptools. Similarly when things will change it most likely will be breaking enough that we'll need a new name, and can't just swap things under the hood.

We can always try to keep compability, as I said. If compability is not possible to acheive, we can try to have the least ammount of breakage possible.

IMHO for not introducing more confusion along users it's prefered for the two to match. Which for me pushes into the direction to go with pyproject-build...

But the entrypoint is not even the recommended way to run the project, it is just there for pipx.
At this point, I think it would just be better for pipx to gain a -m/--module argument in install so that we could do this.
$ pipx install -m build  # install build as module, as opposed to entrypoint
$ pipx -m build  # run the build module

At this point, I think it would just be better for pipx to gain a -m/--module argument in install so that we could do this.
$ pipx install -m build  # install build as module, as opposed to entrypoint
$ pipx -m build  # run the build module

If you're voluntering to make it happen 👍

I don't see how adding a bucketload of complexity to pipx is a reasonable alternative to adding one line in your setup.cfg simply because we can't seem to settle on a name.

The problem isn't as simple just adding a line to setup.cfg...

At this point, I think it would just be better for pipx to gain a -m/--module argument in install so that we could do this.

If you can make that happen it would help other projects using only -m entrypoints too.

If a package does not expose as entry point that should be taken as indication that it should not be decoupled from the Python runtime.  It is for this reason that the pep517 package did not have an entry point.

Well, it shouldn't, at least until/if we implement #104. I am not a user of pipx for this project, the entrypoint was just added because it was requested.
Maybe we should just remove it?

I can't count the times I have been hit by issues that originated years ago. When setuptools was created we also didn't know we would have to change things in the future. Software changes and so needs change, we simply can't predict the future. The entrypoint name can be easily changed, the project name can't. If pyproject-build doesn't make sense anymore we can create a new one and deprecate pyproject-build. I'd like to avoid telling users, the pyproject-build project is deprecated, you should now use this new tool.

I feel like this is actually a good reason to not use a super generic name like build. I'd say that the chance that we'll stop calling modern builds "pyproject" builds or something (assuming we decide to call them that in the first place) is approximately the same order of magnitude as (or lower than) the chance that we find some fundamental flaw in the approach build is taking, and we find that the large existing user base prevents us from making major breaking changes. In other words, there's as good a chance that we will have no choice but to create a new front-end tool with a different name as that the name suddenly seems inappropriate.

The idea is, if things change in the backend, we will try our best to keep the frontend the same, avoiding breakage. I do not feel comfortable naming the project something as implementation/standard dependent as pyproject.

I am happy with other names, though none of the proposals are as searchable as this. I also think that pyproject isn't necessarily specific to PEP 517 — this project doesn't even require you to have a pyproject.toml file! It's just a tool that builds Python projects, and it uses the modern build standard.
We don't really have a good option here, but I think build and python-build are among the worst, because they clash with existing stuff, there are folders called build dropped into your local directory when you actually run the tool as a side-effect of some backends (which may become a source of bugs in some situations) and it's impossible to search for or refer to. Even if we call it just build, people will be forced to call it python-build or something in most contexts, and then there will be confusion about what you are supposed to install with pip, what the name of the project is, etc.
Assuming we decide to unify the name for the CLI tool and the name for the project, I see 4 reasonable choices:
pyproject-build:
Downsides

It's still pretty generic, and people will likely just add it to the litany of hard-to-distinguish Python tools (pyenv, virtualenv, venv, pipenv, pip, pipx, etc).
People may think that you need a pyproject.toml to use it (though most people of this sort don't understand what pyproject.toml is / does, and are probably using setup.py anyway).
It may be seen as associated with PEP 517/518/621/etc, but if we later abandon this approach in favor of something else, the name may seem antiquated. For example, if we had built a tool like this 10 years ago, we might have called it 'egg-factory' or something, and even if we later changed it so that egg-factory produces only wheels, not eggs, it would be hard to blame people for thinking it was an antiquated tool.

Upsides

Searchable.
Pretty obvious that it builds Python packages, rather than Python itself.
The CLI tool and the -m can be named the same thing.
Reasonably easy to remember.

python-build
Downsides

Even more generic.
Clashes with pyenv (though @adamchainz, how do I repro the issue? When I do pyenv install 3.9.0 with build installed via pipx, it seems to work just fine).
A project with this name already exists, and actually builds Python rather than building Python packages.
Clashes to some extent with the nomenclature of some linux distros (e.g. Debian and Arch), which tend to namespace tools with python-. It would have to either be python-python-build or python-build (even though normally it would be python-<modulename>).
Decently hard to search for, particularly when search engines like Google will ignore the - even if you wrap it in quotes.

Upsides:

CLI name is unique enough.
This is already the name people have been using to refer to this project.

build
Downsides

So generic as to be almost meaningless, lacking even the context that this refers to Python. There are almost certainly naming conflicts everywhere.
It will be impossible to search for this and references to this even on your own hard drive, since you probably have dozens or hundreds of build directories on your computer as a result of building Python projects (or possibly even just random stuff).
In order to make the name specific enough that you can actually refer to the project, people will use a different name like python-build, which will cause confusion and open us up to typo-squatting.
The CLI tool being named build seems like a bad idea?

Upsides

Very generic seems more authoritative I guess?

A name mostly-unrelated to the function, possibly randomly generated or nonsense (e.g. zewen, festun, mamongi)
Downsides:

Name does not convey what it does, so it is an additional thing for people to memorize (e.g. pip).
May seem less professional than using a much more generic name.

Upsides:

Incredibly searchable
No problem with ergonomics or name clashes or confusion.
CLI and module can easily be named the same thing.

Writing that out, I'm sort of in favor of picking a random name. We could use a Markov chain and come up with a 5-7 letter pronounceable, searchable and unique name. I'm also on board with moving the whole project to pyproject-build.

Writing that out, I'm sort of in favor of picking a random name.

Ditto. And... with that I'mm cop out of this discussion to avoid the bikeshedding that might follow.

I like it being generic, it means that is the project in charge of building Python packages, period. But I guess this might be personal.
But if the name is too confusing for people, maybe we should as proposed above split this into two different projects. build would be the library, and something like pyproject-build would be the CLI. The two projects could even live in the same repo if that makes sense.
Other possible proposal would be to keep this project as is, with __main__ exposed and create a new project that implements #104, which would be more suitable for a final user tool. There we could go a little bit more crazy, and lose the "minimal dependencies" rule. Distro packagers and people with similar use-cases would use build, end-users would use pyproject-build.
There are a lot of opinions here and a lot of people pulling in different sizes, so I think if we compartementeralized things like that we might be able to better apeal to everyone. Personally, I like the 2nd approach more.
I don't know, this is just me spitballing, let me know what you think...

I really like python -m build, it is clear, simple, and exactly what you mean, and authoritative. How about, if this gets accepted into PyPA, proposing pypa/build or pypa/pypa-build for the repo, python -m build for most users, and pypa-build for the entry point?

How about, if this gets accepted into PyPA

This is essentially a foregone conclusion, I'd say. No one has expressed any opposition to its inclusion and the votes so far are uniformly +1.

I like it being generic, it means that is the project in charge of building Python packages, period. But I guess this might be personal.
But if the name is too confusing for people, maybe we should as proposed above split this into two different projects. build would be the library, and something like pyproject-build would be the CLI. The two projects could even live in the same repo if that makes sense.

Well yes, people do think of it as authoritative if it has a super generic name like this, but at the end of the day no matter what we call it it will sound authoritative because it will be authoritative. We'll add it to the tutorials and give talks about how it's the right way to build your packages, and eventually it will enter the lexicon of Python programmers (or it will get rolled into an omnibus tool and be omnibustool build or whatever). npm, pip and to a lesser extent cargo are all basically short nonsense phrases that sound authoritative because they've been widely adopted.
Another downside I thought of to using nonsense words is that there's probably a limited appetite for completely arbitrary phrases like that, and if we have zewen for builds and crizor for installation, people will probably get them confused.
I would really rather we have an entry point and that we not call the project build. I'm slightly more positive about keeping the project called build and then also having a separate public CLI for it called pyproject-build (though I'd like it even more if they were called pyproject-build and pyproject-build-lib).

Reflecting on this I think pypa-build is actually the best we can do, it's going to live under pypa/build so having it as pypa-build console script names sounds great to me. And we can keep it as python -m build otherwise with build PyPI package name.

Reflecting on this I think pypa-build is actually the best we can do, it's going to live under pypa/build so having it as pypa-build console script names sounds great to me. And we can keep it as python -m build otherwise with build PyPI package name.

I can agree to moving forward with this. We are never gonna find a perfect solution.

Reflecting on this I think pypa-build is actually the best we can do, it's going to live under pypa/build so having it as pypa-build console script names sounds great to me. And we can keep it as python -m build otherwise with build PyPI package name.

Under this proposal, the PyPI project name and package name would be in conflict with the entry point.  Is there a reason why this might be desirable?  I'm not convinced there should be an entry point at all, for my part, if build can only produce wheels for the Python version it's installed under.

Under this proposal, the PyPI project name and package name would be in conflict with the entry point. Is there a reason why this might be desirable?

We can't use the project name as console script as it's too general (build).

I'm not convinced there should be an entry point at all,

Having an entry-point will allow this tool to be used by pipx as is today, and provides a non python -m way to invoke it.

Imagine someone installing build in CI and then proceeding to invoke pypa-build for every job in a multi-Python matrix, only to have it churn out the same wheel

Tools can be abused. The issue is not related at all towards the topic. User can do the same via python -m build too.

We can't use the project name as console script as it's too general and conflicts with existing tools with a high probability (build).

I undertand that.  The question I am asking is why would you not rename the project to pypa-build, so that the project and the entry point align, to avoid unnecessary confusion?

Having an entry-point will allow this tool to be used by pipx as is today, and provides a non python -m way to invoke it.
Tools can be abused. The issue is not related at all towards the topic. User can do the same via python -m build too.

Surely, if this was an important enough reason not to add an entry point to pep517 (https://github.com/pypa/pep517/issues/54), it should have some bearing on build.

Modules with dashes in them introduce issues - pypa-build vs pypa_build, for example. Since the PyPI build name is already dedicated to this project, why make the already clear and someone long-to-type python -m build even longer?
Personally, I don't see a strong reason for an entry point unless it could target other python versions (which personally I don't care about, there are tools for setting up multiple Python versions already). I have an issue every so often that is solved by telling someone to replace pip with python -m pip because they user-installed from one place and are now in an environment some other place and pip & python are not aligned. Certainly, I wouldn't worry too much about optimizing it.

Surely, if this was an important enough reason not to add an entry point

pep517 was never intended to be a user-facing tool. In fact, they thought they could just drop pep517.build since it was not supposed to be a user tool (note: there are 500K references to pep517.build on GitHub).

Personally, I don't see a strong reason for an entry point unless it could target other python versions (which personally I don't care about, there are tools for setting up multiple Python versions already). I have an issue every so often that is solved by telling someone to replace pip with python -m pip because they user-installed from one place and are now in an environment some other place and pip & python are not aligned. Certainly, I wouldn't worry too much about optimizing it.

I don't want this tool to be installed globally/user level, because tools should always be installed into isolated build environments, so that they don't clash with system packages. This is the problem pipx solves. And once you follow this paradigm you need a console script name so that you don't have to type ~/.venvs/here-are-my-tool-venvs/bin/python -m build. Again, we can recommend people to use python -m build if they install things globally (but I would not recommend that) or to use pypa-build if they install it in isolated environments.

pep517 was never intended to be a user-facing tool. In fact, they thought they could just drop pep517.build since it was not supposed to be a user tool (note: there are 500K references to pep517.build on GitHub).

There are two reasons provided in the first reply of the linked issue.  One is what you mention and the other is what I have mentioned.

I don't want this tool to be installed globally/user level, because tools should always be installed into isolated build environments, so that they don't clash with system packages. This is the problem pipx solves. And once you follow this paradigm you need a console script name so that you don't have to type ~/.venvs/here-are-my-tool-venvs/bin/python -m build. Again, we can recommend people to use python -m build if they install things globally (but I would not recommend that) or to use pypa-build if they install it in isolated environments.

Isolation is orthogonal to the issue of pipx itself being globally installed, which means that pipx itself can only link against one Python runtime.

Isolation is orthogonal to the issue of pipx itself being globally installed, which means that pipx itself can only link against one Python runtime.

I don't follow here, you'll need to expand.

I don't follow here, you'll need to expand. But note, no, pipx itself doesn't need to be globally installed.

Let's assume that you have pipx in your path and pipx is installed in the user environment, which is how it is installed by default.  It follows that pipx uses the Python that is available in the user environment [1].  Assume that you have a Python 3.8 development or a build environment and a Python 3.7 user environment.  Calling pipx -m build will invoke build in the pipx environment which uses Python 3.7.  This is almost certainly not what you want.
[1] I believe it actually uses the Python version which was active at the time when it created its shared venv, but more often than not, this is going to be the user Python.

I think there are still compelling reasons to just not name this package build, irrespective of the entry point issue. The practical disadvantages of it being named build far outweigh any benefits from "it sounds simple and authoritative".
I think I would prefer pyproject-build to pypa-build (because pyproject-build describes what it actually does, and pypa-build just describes what github org it lives under), but both of those avoid all the worst disadvantages of the build name.

I undertand that. The question I am asking is why would you not rename the project to pypa-build, so that the project and the entry point align, to avoid unnecessary confusion?

It is not certain that the project will live under PyPA for all its lifetime. As I pointed how previously, entrypoint names are easily changed, the project name isn't.

Personally, I don't see a strong reason for an entry point unless it could target other python versions (which personally I don't care about, there are tools for setting up multiple Python versions already). I have an issue every so often that is solved by telling someone to replace pip with python -m pip because they user-installed from one place and are now in an environment some other place and pip & python are not aligned. Certainly, I wouldn't worry too much about optimizing it.

I agree with you here, but I am not the user for this, and you probably aren't either :stuck_out_tongue:, so I'll defer to @gaborbernat and @pganssle with a warning that I think it may result in confusion for some users. I'd suggest to only expose an entrypoint once/if/when #104 is implemented.

I think there are still compelling reasons to just not name this package build, irrespective of the entry point issue. The practical disadvantages of it being named build far outweigh any benefits from "it sounds simple and authoritative".

I think build is fine, but I can see the problems with it. Similarly, I can also see the problems with the other names.
Anyway, this already resulted in too much bikeshed. I think there is a consensus that no perfect, or near-perfect, solution is possible. And it does seem some of us have diverging opinions.
I'd like to vote to keep the project name, build, and rename the entrypoint to pypa-build, as @gaborbernat suggested, or pyproject-build.
@gaborbernat @pganssle are any of you able to state your final position on the matter? If so, please do so that we can make a final decision.

I'm -1 on keeping the build name, +1 on the entry point being named pyproject-build, and I'd prefer if the module were also named pyproject_build.
build is easily the worst name of the lot.

Calling pypa-build (or a theoretical pipx -m build) will invoke build in the pipx environment which uses Python 3.7. This is almost certainly not what you want.

For pure python projects the version you're building under from does not matter. If you're building a project that has C-extensions then it does. However, the isoalted build environment and the python environment build is running under do not have to be the same. The build project might be running under 3.8, but allow you to create isolation environments under python 3.7 or 2.7. pypa-build could easily get (soon) a --python flag that allow you to specify the isolation environment (and under what your build is happening). This would follow the logic virtualenv works. You can install it once, and then use it to create different python versions, but defaults to self. This later issue though is only a problem for c-extension project, most libraries are universal though.

I'd suggest to only expose an entrypoint once/if/when #104 is implemented.

For the sake of universal wheels I'd hope for earlier. To be fare I expect #104 to be implemented soon (next month or so). I vote to not keep build, and strong +1 for pyproject-build, and +1 for pypa-build. So I guess we go with pyproject-build then?

I vote to not keep build, and strong +1 for pyproject-build, and +1 for pypa-build. So I guess we go with pyproject-build then? I'm happy to keep the project name/structure as is.

Can you clarify on the name? I am having difficulties parsing these two parts.

I vote to not keep build

I'm happy to keep the project name/structure as is.

The project structure I think we can keep as is, also the -m name. I don't think we should keep the console script build. I prefer the strongest pyproject-build, but I can also live with pypa-build.

To be fare I expect #104 to be implemented soon (next month or so).

I am probably not going to work on it for the time being, I have already poured a lot of time into this in a stretch to get this moved over to PyPA and neglected some other projects, including some that may impact me financially. I am happy to review and give feedback anyway.

I'll do this part 👍

The project structure I think we can keep as is, also the -m name. I don't think we should keep the console script build. I prefer the strongest pyproject-build, but I can also live with pypa-build.

Okay, thanks for clarifying. And the project name?

I'll do this part +1

Thanks!

Okay, thanks for clarifying. And the project name?

Can remain build IMHO 🤷 Unless you don't mind in which case can go with @pganssle proposal.

I'd prefer it to stay build. So I guess we are staying with build and renaming the entrypoint to pyproject-build.
If anyone has a major reason why we should not proceed with this please let me know now.

I like pyproject-build as much as pypa-build; and I really like python -m build over python -m pyproject_build!

It is not certain that the project will live under PyPA for all its lifetime. As I pointed how previously, entrypoint names are easily changed, the project name isn't.

Which is better, maintaining consistency, aiding discovery and abating confusion, or attempting to account for the unlikely eventuality that 'pyproject' is no longer relevant, while this package is?  I find the insistence on using ambiguous, quirky or obscure names for packaging tools baffling; and unless there is very good reason not to, developers should align the package name with the entry point and the project on PyPI.

These can't be aligned if there is a dash in the name. pyproject-build would be the entry point, pyproject_build would be the module. Image if pip was called pypackage-installer  / python -m pypackage_installer. That alone would probably cause more confusion than just python -m build vs. pyproject-build when standalone.
I would view "normal" usage as either in a virtual environment or on CI, and both cases its always better to use python -m. It doesn't seem to me that pipx is a good candidate for a tool like pip, and therefore a good candidate for build either? I always felt pipx was more for python packages that wanted to be "standalone" and hide the fact they were in the Python ecosystem.

build wants to be also standalone. We could have written in Rust, and served its purpose just as well. build is a frontend, and interacts with the build backends via subprocess calls and the PEP-517 API. It just happens to be implemented in Python.

These can't be aligned if there is a dash in the name. pyproject-build would be the entry point, pyproject_build would be the module. Image if pip was called pypackage-installer  / python -m pypackage_installer. That alone would probably cause more confusion than just python -m build vs. pyproject-build when standalone.

Is build more obvious?  Would you rather imagine that pypackage-installer's package was called pip instead of pypackage_installer?  Why would you think that a script called pyproject-build would import a package called just build?  Why would the project not be called the same as the script, which is called the same as the package, with the caveat that Python identifiers cannot contain hyphens?

build wants to be also standalone. We could have written in Rust, and served its purpose just as well. build is a frontend, and interacts with the build backends via subprocess calls and the PEP-517 API. It just happens to be implemented in Python.

I don't know what the relevance of writing build in another language is - it would not be invocable with -m unless it were packaged as an extension.  You wouldn't call the Rust executable 'build', either.


Simplify login to Azure from GitHub Actions (remove secrets)

GitHub teams plan releasing new OpenID Connect with cloud providers, such as Azure.
We should update our repositories to enhance security, by removing secrets.
See this page to learn more.

This GitHub feature is now GA, as described on this page. We should configure OpenID Connect with Azure, following this page.

As we now move to AWS, this feature won't be planned.


Update setuptools to 67.6.1 and wheel to 0.40.0

This PR:

Updates setuptools from 63.4.3 to 67.6.1.
Updates wheel from 0.38.4 to 0.40.0.

Of note, the setuptools update introduces more strict parsing of version specifiers (some invalid but previously accepted package version strings will now be rejected by setuptools, if they don't conform to PEP 440 and PEP 508).
If errors are encountered installing packages due to invalid package version strings, then users will need to update to fixed versions of those packages, or else pin to a previous buildpack release until the affected package is fixed.
For more information, see:

https://setuptools.pypa.io/en/stable/history.html#v66-0-0
https://setuptools.pypa.io/en/stable/history.html#v67-0-0
https://peps.python.org/pep-0440/
https://peps.python.org/pep-0508/

In addition, changes have been made to the way setuptools handles editable installs, that may affect some projects using editable mode (-e) depending on the project layout. See:

https://setuptools.pypa.io/en/stable/history.html#v64-0-0
https://setuptools.pypa.io/en/stable/userguide/development_mode.html

Full changelogs:

https://setuptools.pypa.io/en/stable/history.html#v67-6-1
https://wheel.readthedocs.io/en/stable/news.html

GUS-W-12346556.
GUS-W-13011106.

https://devcenter.heroku.com/changelog-items/2570


Baic authentication ES clutser in production

i want to set basic authentication only username:password to ES clutser. i have created kubernetes secret and added in values.yaml file also added xpack.security.enabled: true.
my web app would be sending request over simple HTTP only.
Please let me know if it is possible just set basic authentication username: credentials without setting up SSL transport layer security.
UPDATE
i am done with basic setup, mean basic auth and certificate creation working well also cluster is up.
but when i am sending curl request getting
curl localhost:9200
curl: (52) Empty reply from server
but when sending curl with --insecure or with -k getting response

{
  "name" : "elasticsearch-master-0",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "sUVANxDTQI2L8iSYBXIijg",
  "version" : {
    "number" : "7.3.2",
    "build_flavor" : "default",
    "build_type" : "docker",
    "build_hash" : "1c1faf1",
    "build_date" : "2019-09-06T14:40:30.409026Z",
    "build_snapshot" : false,
    "lucene_version" : "8.1.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

any solution of this --insecure i think error occurring due to self-sign certificates.
elasticsearach.yaml file
esConfig:
  elasticsearch.yml: |
    xpack.security.enabled: true
    xpack.security.transport.ssl.enabled: true
    xpack.security.transport.ssl.verification_mode: certificate
    xpack.security.transport.ssl.keystore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
    xpack.security.transport.ssl.truststore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
    xpack.security.http.ssl.enabled: true
    xpack.security.http.ssl.truststore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
    xpack.security.http.ssl.keystore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
    xpack.security.authc.realms.native.local.order: 0

i just want to run on HTTPS and simple basic password, if anyone can please help.
is it okay if i remove from yaml file
xpack.security.http.ssl.enabled: true
    xpack.security.http.ssl.truststore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
    xpack.security.http.ssl.keystore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12

by removing above three line it's working with curl without insecure mode.
Thanks. Please help

With this steps we enable xpack security without SSL on Google Kubernetes Engine.
1.- Edit config.yml add
extraEnvs:
  - name: ELASTIC_PASSWORD
    valueFrom:
      secretKeyRef:
        name: elastic-credentials
        key: password
  - name: ELASTIC_USERNAME
    valueFrom:
      secretKeyRef:
        name: elastic-credentials
        key: username

esConfig:
  elasticsearch.yml: |
    xpack.security.enabled: true

2.- Create credentials on GKE
kubectl -n default create secret generic elastic-credentials  --from-literal=password=$password --from-literal=username=elastic

Change $password *

3.- Install on GKE
helm upgrade --wait --timeout=1500 --install \
  --values ./config.yaml elasticsearch elastic/elasticsearch

I hope this help, i haven't SSL on my cluster.

Or maybe you are using
bin/elasticsearch-certutil cert ...

And not
bin/elasticsearch-certutil http

Check SSL/TLS

@sanvir10 thanks working well. how about
esConfig:
  elasticsearch.yml: |
    xpack.security.enabled: true
    xpack.security.transport.ssl.enabled: true
    xpack.security.transport.ssl.verification_mode: certificate
    xpack.security.transport.ssl.keystore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
    xpack.security.transport.ssl.truststore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
    #xpack.security.http.ssl.enabled: true
    #xpack.security.http.ssl.truststore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
    #xpack.security.http.ssl.keystore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
    xpack.security.authc.realms.native.local.order: 0

you must be commenting http.ssl

@harsh4870 Can you share how are you creating elastic-certificates.p12?
I did this steps but i get error
1.- bin/elasticsearch-certutil ca      I used bin/elasticsearch from local folder maybe here is the error
2.- bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
3.- I Uploaded the elastic-certificates.p12 to secrets on GKE
4.-
I have 7 nodes on my cluster(3 master, 2 data and  2 clients) but each group have diferent pod name:
1- elasticsearch-master
2.-elasticsearch-data
3.-elasticsearch-client
I did some change to the script
from
...elasticsearch-certutil cert --name security-master --dns security-master --ca /tmp/elastic-stack-ca.p12 --pass '' --ca-pass '' --out /tmp/elastic-certificates.p12" && \

to
...elasticsearch-certutil cert --name security-master --dns elastisearch-master, elasticsearch-data,elasticsearch-client --ca /tmp/elastic-stack-ca.p12 --pass '' --ca-pass '' --out /tmp/elastic-certificates.p12" && \

But this don't work yet :(.

@sanvir10  i am not 100% sure about issue but i followed this article only in comment someone suggested to use kubernets svc as DNS name.
https://pimwiddershoven.nl/entry/deploy-a-secure-instance-of-elasticsearch-on-kubernetes
please you can look it once

@harsh4870  thanks so much i will che it.
Regards


Freeing up the reference to PropertiesConfiguration after loading seg…

…ment metadata
We were holding on to the propertiesConfiguration object after loading the segment metadata which consumed extra memory. Even though the overhead is quite small for each segment, it adds up. In one of the environment with 25k segments, this attributed to 3G. With this change, the memory footprint reduced to ~250mb. This is lot of saving not just in terms of memory usage but also impact on GC since these are long lived and get moved around every time there is a major compaction.

Codecov Report

Merging #2996 into master will decrease coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2996      +/-   ##
==========================================
- Coverage   69.92%   69.89%   -0.04%
==========================================
  Files         913      913
  Lines       43288    43290       +2
  Branches     5917     5917
==========================================
- Hits        30269    30257      -12
- Misses      10990    10998       +8
- Partials     2029     2035       +6

Impacted Files
Coverage Δ

.../pinot/core/segment/index/SegmentMetadataImpl.java
81.11% <100%> (+0.13%)
:arrow_up:

...in/pinot/core/query/pruner/ValidSegmentPruner.java
57.14% <0%> (-28.58%)
:arrow_down:

...impl/dictionary/DoubleOnHeapMutableDictionary.java
68.88% <0%> (-13.34%)
:arrow_down:

...mpl/dictionary/DoubleOffHeapMutableDictionary.java
72.72% <0%> (-10.91%)
:arrow_down:

...ore/query/scheduler/resources/ResourceManager.java
87.09% <0%> (-9.68%)
:arrow_down:

...afkaHighLevelConsumerBasedRoutingTableBuilder.java
92.3% <0%> (-3.85%)
:arrow_down:

...inot/transport/netty/NettyTCPClientConnection.java
82.31% <0%> (-3.41%)
:arrow_down:

...e/operator/dociditerators/MVScanDocIdIterator.java
63.63% <0%> (-3.04%)
:arrow_down:

.../pinot/core/query/scheduler/PriorityScheduler.java
78.08% <0%> (-2.74%)
:arrow_down:

.../controller/helix/core/SegmentDeletionManager.java
77.58% <0%> (-2.59%)
:arrow_down:

... and 8 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cd98557...28750ae. Read the comment docs.


http4s server generation #68

@blast-hardcheese could you please take a look?

@cponomaryov Definitely, though I can't do this immediately.
From the initial review, it looks solid, and the contribution is very much appreciated.
Are you able to get by for now either using the CLI flags with a prebuilt jar or via publishing to a local repository?

@blast-hardcheese we would like to use it in production, so it would be nice to have it in maven central maybe with some experimental version. If it's not possible, we will wait for your review.

@blast-hardcheese I made changes according to your comments. Could you please take a look when you have time. Thanks.

@blast-hardcheese thanks, when we can expect a new version of guardrail-maven-plugin with these changes?

@cponomaryov I'm waiting for maven central to sync

@blast-hardcheese thanks

@cponomaryov OK, it should be available in five to ten minutes


sample app kinesis_video_gstreamer_audio_video_sample_app leads to Failed to submit frame to Kinesis Video client. status: 0x52000085

Hi, I am using the sample app to send audio and video to a KVS.
./kinesis_video_gstreamer_audio_video_sample_app test

This seems to work for a while and then after some time it stops streaming. The logs have:
[2020-02-24 16:01:30]-WARN-putKinesisVideoFrame(): Failed to submit frame to Kinesis Video client. status: 0x52000085 decoding timestamp:<PHONE_NUMBER>0 presentation timestamp:<PHONE_NUMBER>0

I am running on a RaspberryPi 4 and using a Logitech C920e to record both audio and video.
Could you suggest as to what this error means and how to address it?
status: 0x52000085

@mistersingh179 the error you see is defined here:
https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/blob/master/kinesis-video-pic/src/client/include/com/amazonaws/kinesis/video/client/Include.h#L185
Unfortunately, the public AWS docs have not been updated to reflect this.
The error happens in multi-track mode when the PIC is attempting to AV/sync the frames. It has to hold some of the frames from one track so the other track can 'catch up' to allow the frames from this track to proceed. This error indicates that one of the tracks does not produce frames and as a result the frames from the other track (the one that's putKinesisVideoFrame is called on) exceeds the limit.
Normally, this happens when the video frames get delayed.
Could you enable the verbose logging, collect the logs and attach them?

hi @MushMal I just re-ran it with GST_DEBUG=4. can you confirm that this is what you meant with –  enabling verbose logging?
Also, this is hard to reproduce as it doesn't fail right away, but only after I let it run for many hours.
What would you suggest I do to prevent it from completely failing. Right now, when it hits this error it never recovers and I have to restart the process to resolve it. Is it possible to have it flush the old frames and just stream new data?
I do have the following set to get higher resolution. Could this be contributing to the problem?
video_caps_string = "video/x-raw,framerate=10/1, format=I420, width=1280, height=720";

btw so far the logs show this:
[DEBUG][2020-02-24 22:33:18] fragmentAckReceivedHandler invoked
[DEBUG][2020-02-24 22:33:18] Reporting fragment ack received. Ack timecode 325833
[DEBUG][2020-02-24 22:33:18] postReadCallback(): Wrote 2348 bytes to Kinesis Video. Upload stream handle: 0
[DEBUG][2020-02-24 22:33:18] postReadCallback(): Pausing CURL read for upload handle: 0
0:05:32.000177278  4937  0x1956c60 INFO                 v4l2src gstv4l2src.c:957:gst_v4l2src_create:<videosrc> sync to 0:05:29.500000000 out ts 0:05:31.285745669
0:05:32.100203868  4937  0x1956c60 INFO                 v4l2src gstv4l2src.c:957:gst_v4l2src_create:<videosrc> sync to 0:05:29.600000000 out ts 0:05:31.385737932
0:05:32.200219753  4937  0x1956c60 INFO                 v4l2src gstv4l2src.c:957:gst_v4l2src_create:<videosrc> sync to 0:05:29.700000000 out ts 0:05:31.485732379
0:05:32.300301009  4937  0x1956c60 INFO                 v4l2src gstv4l2src.c:957:gst_v4l2src_create:<videosrc> sync to 0:05:29.800000000 out ts 0:05:31.595626550
0:05:32.400308172  4937  0x1956c60 INFO                 v4l2src gstv4l2src.c:957:gst_v4l2src_create:<videosrc> sync to 0:05:29.900000000 out ts 0:05:31.695631109
0:05:32.500338021  4937  0x1956c60 INFO                 v4l2src gstv4l2src.c:957:gst_v4l2src_create:<videosrc> sync to 0:05:30.000000000 out ts 0:05:31.795616761
0:05:32.604106770  4937  0x1956c60 INFO                 v4l2src gstv4l2src.c:957:gst_v4l2src_create:<videosrc> sync to 0:05:30.100000000 out ts 0:05:31.895862104
0:05:32.704131228  4937  0x1956c60 INFO                 v4l2src gstv4l2src.c:957:gst_v4l2src_create:<videosrc> sync to 0:05:30.200000000 out ts 0:05:31.995845645
0:05:32.804129520  4937  0x1956c60 INFO                 v4l2src gstv4l2src.c:957:gst_v4l2src_create:<videosrc> sync to 0:05:30.300000000 out ts 0:05:32.095863409
0:05:32.904214941  4937  0x1956c60 INFO                 v4l2src gstv4l2src.c:957:gst_v4l2src_create:<videosrc> sync to 0:05:30.400000000 out ts 0:05:32.195795710

I take it this means that when the delta is higher than 60 seconds, is when the software fails?
How can I increase this buffer from 60 to 600? Would you recommend I do that?

@mistersingh179 it's hard to tell whether the media pipeline will recover by itself or not - it depends on the actual encoder and the media source.
Here is the location where you can change the value of the number of frames it stores in the temp buffer before flushing for multi-track.
https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/blob/master/kinesis-video-pic/src/mkvgen/include/com/amazonaws/kinesis/video/mkvgen/Include.h#L134
Overflowing this buffer will cause the error you are seeing. For 30 fps this means 2 seconds drift of audio/video before this error happens.
Suggest a quick fix of increasing 60 to something more - say double it. NOTE: This will also increase the memory pressure and add latency in case this buffer starts getting full (until the frames are flushed).
There are no public methods to flush the frames in.
Also, when collecting the logs, it would be good to collect gstreamer and KVS logs both in verbose mode. For GSTreamer GST_DEBUG=4 is good. For KVS, you could use
https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/blob/master/kinesis-video-c-producer/samples/KvsVideoOnlyStreamingSample.c#L93
or depending on which asset you are using

thanks @MushMal.  i am experimenting with increasing the frame buffer count.
Can you tell me what in the logs will tell me how many frames drift i have? Is it this:

0:05:32.000177278  4937  0x1956c60 INFO                 v4l2src gstv4l2src.c:957:gst_v4l2src_create: sync to 0:05:29.500000000 out ts 0:05:31.285745669

I am not really familiar with the gst_v412src logging. Need to investigate this further. The important question I guess is to know whether this issue is persistent or transient and if persistent whether video frames are still being produced or not (and, if they are produced then what's the delta between the frames).
It's possible that your video source simply stopped working?

hi @MushMal i tried today with different values of frame buffer and the issue is persistent. After a while it stops streaming. The logs are below. The remainder of the logs are just the same failure message repeated.
What do you recommend my next step be?
[2020-02-25 16:55:23]-DEBUG-Kinesis Video client and stream metrics
	>> Overall storage byte size: 134217728
	>> Available storage byte size: 134012785
	>> Allocated storage byte size: 204943
	>> Total view allocation byte size: 576064
	>> Total streams frame rate (fps): 35222
	>> Total streams transfer rate (bps): 154352 (150 Kbps)
	>> Current view duration (ms): 991
	>> Overall view duration (ms): 9041
	>> Current view byte size: 34603
	>> Overall view byte size: 194365
	>> Current frame rate (fps): 35222.4
	>> Current transfer rate (bps): 154352 (150 Kbps)
[2020-02-25 16:55:23]-DEBUG-postReadCallback(): Wrote 34603 bytes to Kinesis Video. Upload stream handle: 7
[2020-02-25 16:55:23]-DEBUG-postReadCallback(): Pausing CURL read for upload handle: 7
[2020-02-25 16:55:23]-DEBUG-postWriteCallback(): Curl post body write function for stream with handle: test and upload handle: 7 returned: {"EventType":"RECEIVED","FragmentTimecode":1230352,"FragmentNumber":"91343852333183928753240643324634405752952168380"}

[2020-02-25 16:55:23]-DEBUG-fragmentAckReceivedHandler invoked
[2020-02-25 16:55:23]-DEBUG-Reporting fragment ack received. Ack timecode 1230352
[2020-02-25 16:55:23]-DEBUG-postWriteCallback(): Curl post body write function for stream with handle: test and upload handle: 7 returned: {"EventType":"BUFFERING","FragmentTimecode":1239393,"FragmentNumber":"91343852333183928758192403481775929094058995378"}

[2020-02-25 16:55:23]-DEBUG-fragmentAckReceivedHandler invoked
[2020-02-25 16:55:23]-DEBUG-Reporting fragment ack received. Ack timecode 1239393
[2020-02-25 16:55:23]-DEBUG-postWriteCallback(): Curl post body write function for stream with handle: test and upload handle: 7 returned: {"EventType":"PERSISTED","FragmentTimecode":1230352,"FragmentNumber":"91343852333183928753240643324634405752952168380"}

[2020-02-25 16:55:23]-DEBUG-fragmentAckReceivedHandler invoked
[2020-02-25 16:55:23]-DEBUG-Reporting fragment ack received. Ack timecode 1230352
[2020-02-25 16:55:23]-DEBUG-postReadCallback(): Wrote 4967 bytes to Kinesis Video. Upload stream handle: 7
[2020-02-25 16:55:23]-DEBUG-postReadCallback(): Pausing CURL read for upload handle: 7
[2020-02-25 16:55:28]-WARN-putKinesisVideoFrame(): Failed to submit frame to Kinesis Video client. status: 0x52000085 decoding timestamp:<PHONE_NUMBER>00 presentation timestamp:<PHONE_NUMBER>00
[2020-02-25 16:55:28]-WARN-putKinesisVideoFrame(): Failed to submit frame to Kinesis Video client. status: 0x52000085 decoding timestamp:<PHONE_NUMBER>66 presentation timestamp:<PHONE_NUMBER>66
[2020-02-25 16:55:28]-WARN-putKinesisVideoFrame(): Failed to submit frame to Kinesis Video client. status: 0x52000085 decoding timestamp:<PHONE_NUMBER>33 presentation timestamp:<PHONE_NUMBER>33

Seems that you are getting debug logs. Do you see the printout from putFrame:
https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/blob/master/kinesis-video-pic/src/client/src/Stream.c#L716
This should show the trackId and we can see whether the video simply stopped all together.

@MushMal no i don't see this line in my logs ever. so would this mean that i am not logging properly?
Below is my current kvs_log_configuration. What do you suggest i change it to get the correct logs:
log4cplus.rootLogger=DEBUG, KvsConsoleAppender, KvsFileAppender

#log4cplus.logger.MemoryCheck=TRACE, KvsConsoleAppender

#KvsConsoleAppender:
log4cplus.appender.KvsConsoleAppender=log4cplus::ConsoleAppender
log4cplus.appender.KvsConsoleAppender.layout=log4cplus::PatternLayout
log4cplus.appender.KvsConsoleAppender.layout.ConversionPattern=[%-5p][%d] %m%n

#KvsFileAppender
log4cplus.appender.KvsFileAppender=log4cplus::DailyRollingFileAppender
log4cplus.appender.KvsFileAppender.File=./log/kvs.log
log4cplus.appender.KvsFileAppender.Schedule=HOURLY
log4cplus.appender.KvsFileAppender.CreateDirs=true
log4cplus.appender.KvsFileAppender.layout=log4cplus::PatternLayout
log4cplus.appender.KvsFileAppender.layout.ConversionPattern=[%D]-%p-%m%n

Hi @mistersingh179 ,
You can rerun the app with environment variable "export DEBUG_DUMP_FRAME_INFO=TRUE". That should give you the print of frame info with timestamp and track id. Thanks.

@zhiyua-git thank you , this helps. I just re-ran it with DEBUG_DUMP_FRAME_INFO set to true. I can now see that its printing as each frame is uploaded. Will wait till it crashes and then send logs.

@mistersingh179 - was it crashing before? If so, could you please open a separate issue and include the crash stack/dump?

@MushMal by crash i meant to say that it leads to the error i created this ticket with:
[2020-02-25 16:55:28]-WARN-putKinesisVideoFrame(): Failed to submit frame to Kinesis Video client. status: 0x52000085 decoding timestamp:<PHONE_NUMBER>00 presentation timestamp:<PHONE_NUMBER>00
[2020-02-25 16:55:28]-WARN-putKinesisVideoFrame(): Failed to submit frame to Kinesis Video client. status: 0x52000085 decoding timestamp:<PHONE_NUMBER>66 presentation timestamp:<PHONE_NUMBER>66
[2020-02-25 16:55:28]-WARN-putKinesisVideoFrame(): Failed to submit frame to Kinesis Video client. status: 0x52000085 decoding timestamp:<PHONE_NUMBER>33 presentation timestamp:<PHONE_NUMBER>33

I have been running it now with DEBUG_DUMP_FRAME_INFO=true for a 6 hours now and so far it has not resulted in error 0x52000085.

@mistersingh179 have you had a chance to get more data on this?

@MushMal i am unable to reproduce this issue anymore. this would mean an issue with either the OS or camera. Closing the issue. Thank you for your help @MushMal @zhiyua-git


Add isset() to express?

In PHP you can do
if( isset($var) ) { ... }
In JavaScript you often use
if( typeof var != 'undefined' ) { ... }
for similar functionality.
It would be great to have this functionality built into express by default, to clean up the code a little bit.
What do you guys think?

Here's the code to implement.
function isset(){
    if( typeof var !== 'undefined' ) {
        return true;
    }
    return false;
}

If anything, this would go in it's own isset npm module.
However, Javascript isn't quite like PHP, and it's probably best to use thing !== undefined (specifically, using strict equality, !== or === where type coercing will not happen.

typeof var != 'undefined'

Also, typeof isn't necessary; thing !== undefined is better and shorter.

Typeof is necessary, see here https://stackoverflow.com/questions/2281633/javascript-isset-equivalent

I think there is a little confusion here: PHP is to JavaScript, not Express. An isset-like function would need to be part of Node.js or JavaScript, rather than the Express API.

@smithb1994 If you are try to differentiate between the undefined value, and it not being a property on an object, using obj.hasOwnProperty('foo') is generally considered better.
if you are trying to check whether a scope-level variable exists, i.e. if var foo exists, it is a better idea to write the code so that var foo always exists.

Typeof is not necessary when testing for the presence of an object member property. One can simply do obj.prop !== undefined, because if the property doesn't exist the lookup will return undefined.
Typeof is necessary when testing for the presence of a variable in scope. Without typeof you will get a reference error when the variable does not exist.  There is never a time when one should be doing that, however.  You should either know what is in your scope, or you should be accessing global values directly via global or window.  That use case also could not be abstracted into an isset() function, because trying to pass a variable that doesn't exist to the function would trigger a reference error.
As @Fishrock123 and @dougwilson have said, this is not in the purview of express, which only concerns itself with request routing.  You might consider using something like Lodash if you're looking for a collection of utility functions, which includes _.isUndefined().

@ChiperSoft  Lodash is perfect! Thanks!


Make the WebGUI remotely accessible

Is your feature request related to a problem? Please describe.
When i try to load the page it just 'keeps loading'  (like in issue:  "eternal loading #101")

Describe the solution you'd like
I just want the page to load when i remotely access it (or with a reverse proxy), so i can access it from multiple locations.
Describe alternatives you've considered
I've tried to run it with a reverse proxy on the same machine as where perplexica is running, but i get the same result.
Additional context

Hi, please see this. Since we don't already have your private IP address we've left it for the user to do it themselves.

Ah this works!  \o/
But only if i access it directly on http://<server_ip>:3000 .
When i use a reverse proxy it still keeps loading.
I hope this can be fixed in the future... but for now i'm happy it works :)
Thank you.

Following...

Same issue. Works on local network but i am unable to set it up behind the reverse proxy manger.

Same here

Same here


New module for "example data" and/or links to how to use the data

💡 Description

This can maybe be a thumbnail image or a plot or ???. It will most likely need to be curated by the node, but we should maybe include something like this in our designs to encourage the content curation teams to provide something like this.

Past usages of data has come up in User Testing where people want to see papers that have used the data, but not yet that they want to see visualizations of it. Are we taking data that has already been visualized by someone affiliated with a node and putting a screenshot of the data? Do we have any examples of what's being mentioned here right now?

Completed in FInal Designs:
https://www.figma.com/file/Gi5Cy9DFEhqY2VkhYkOQCD/Final-Designs?type=design&node-id=0-1&mode=design


Option to save preserving objects order

Hi,
I'm manipulating some xml derivated formats where order has some importance (child objects in a graphical container and layers) .
Is it possible to have an option to preserve the order in a modified and saved xml file ?
Regards.

Mini-XML always preserves the order and hierarchy of nodes in the XML document.


B 21036 enforce dodid and emplid int

B-21036
Summary
Enforced DODID for all affiliations and when Coast Guard also enforces EMPLID. This is a form validation change and endpoint-specific validation change
How to test

Login as a SC
Navigate to add a customer (See screenshots below)
Create a new customer and test DODID and EMPLID requirements

Screenshots

508 Screenshot

So sorry for the conflicts

Looks great and functions as expected!
Would you be open to changing the DOD ID to DoD ID (or vice versa, not sure what the gov prefers) just so they match?

Resolved in https://github.com/transcom/mymove/pull/13649/commits/98b7f778cbfa6ac16f12f030e4c2c0752478cca2


R.omit allows string (not array)

So this should be prevented with typings, because one may think that one may pass string if there is only one property to omit.

Ramda allowed ArrayLike to be passed in R.omit, i.e. the following two cases are considered the same:
R.omit('ad', {a: 1, b: 2, c: 3, d: 4}); //=> {b: 2, c: 3}
R.omit(['a', 'd'], {a: 1, b: 2, c: 3, d: 4}); //=> {b: 2, c: 3}

And AFAIK there's no way to allow ArrayLike but disallow string since string satisfies with ArrayLike.

I can verify @ikatyang's explanation here; disallowing string here would simultaneously break input using e.g. ImmutableJS List, though I'd considered the string variant a legitimate under-documented feature of Ramda as well. I get where you're coming from here though @whitecolor.
Maybe we should be open to PRs for a branch simplifying ArrayLike to Array for those who'd value the clarity over flexibility?

Well in docs it is stays clearly Array. And it assumes a list of props.
Why ArrayLike in typings is used not just Array?

I at the time opted to err toward a descriptive approach (-> allow what works in Ramda) over a prescriptive one (-> allow what Ramda documents), figuring it'd cover more legitimate use-cases, notably alternate array implementations.
As Ika noted, one of the challenges here is it's actually kinda hard to allow those while disallowing string here (though string also works in Ramda, at which point one might argue it to be legitimate).
I'd be open to having branches for both approaches, and if people would prefer the clarity over flexibility by default, I wouldn't object to having your version as the default. I suppose one might argue those that want the ArrayLike support would be power-users, while for new users it may admittedly make sense to prevent accidental misuse.

String works but it really should be not allowed by typing to avoid silly errors and disambiguation.
It is a common case to omit one prop and people will often make mistake like:
R.omit('secret')

String here is really non-common use case and people always can do it:
R.omit('abcd' as any)
// or
R.omit('abcd'.split(''))

One in a million probably will. =)

So will be fixed?

I'm not actively working on this repo; Ika I think had been more concerned about getting a DefinitelyTyped compatible release out.

In the R.omit case, I think it's fine to remove ArrayLike support since nobody uses ArrayLike to store keys and it can avoid the 'ad' === ['a', 'd'] confusing.

Might it be elegant to have one branch (set) say type List<T> = ArrayLike<T>, another type List<t> = Array<t>?

It's okay to me, but won't it become more confusing to newbies? and I think our goal is to provide one most useful branch instead of adding more branches (if DT is available, we can just put one version there).

These are good questions.

won't it become more confusing to newbies?

I guess that could be said of either:

many branches (needs docs to explain)
the current behavior, consistent with Ramda but deemed confusing by the OP (and presumably others)
inconsistent behavior (handling omit different from other functions)

I think our goal is to provide one most useful branch instead of adding more branches (if DT is available, we can just put one version there).

Yeah.
How would you see it then? It sounds like we're both trying to consider new users here, yet reaching different conclusions on how to do that.

I personally prefer the current behavior but the omit case is really confusing with string as the first parameter, or we'll have to wait for the subtraction type support (Microsoft/TypeScript#4183), which is not on the TS roadmap.

The reason we have 4 branches is about the performance concern, but it seems it's not a problem now? then I'd like to remove other branches since we'll send only one branch PR to DT eventually.

The reason we have 4 branches is about the performance concern, but it seems it's not a problem now?

If so then great.
If there's demand for different branches I don't mind. Guess if so we'll hear about it.
So different trade-offs among branches (what did I miss?):

ArrayLike: enabled #113 (ReadOnlyArray) and #115 (ImmutableJS) but also strings, causing correct (descriptive) yet confusing behavior (this thread).
placeholder overloads: enabled R.__ but gave many overloads. so far no complaints about performance though.

I guess there will be different users with different preferences, though admittedly maintenance complexity is a consideration as well.
If alternate branches could bring options for power users without imposing a burden on maintenance, that'd sound nice as long as some readme notes could tell people what's what. That said, you're the one doing most of the work here now, so I respect your preference.

If it's just a simple option (e.g. ArrayLike -> ReadonlyArray , which seems no need to test it), I don't mind to add branches for it.
From GitHub searching, there's no one uses branches other than dist, so I think it should be safe to drop other branches (no updates for them and remove mention on README)? and the future branch will look like:

dist
dist-strict-array

And if there's more options in the future, we'll just have one-enabled and all-enabled branches, e.g.

dist
dist-strict-array
dist-some-option-1
dist-some-option-2
dist-all-enabled

Fair enough. :)

i'm not sure, but those branches look like the unnecessary complication

well, if we drop the features altogether, wouldn't #113 and #115 just get refiled? it'd sound like fixing one issue and breaking two others again. who's to say which use-cases are legitimate, and which aren't?
that said, if we have usage stats for branches, then if it turns out no-one uses them we can still just ditch them. heck, I do imagine usage would be marginal, so perhaps a readme note of "change this List definition to use ArrayLike" could suffice...


RaptorJIT load: follows symlinks recursively and loads same audit.log multiple times

In case of named Snabb programs their SHM directories contain a name symlink that leads to the same directory. When pointing RaptorJIT load: at such a SHM directory it will try to load the audit.log ten times instead of only once.
Possibly we should either not follow symlinks at all or somehow detect if we attempt to load the same audit.log and avoid that.

Had a first attempt at fixing this but the primitive FileReference>>isSymlink doesn't seem to be working. Could be a build issue with the VM. Have to resolve that first methinks.


Unable to login in npm sencha registry, and https://www.sencha.com/extreact not found

Expected Behavior
Install scoped @ext packages normally.
Current Behavior
I tried to login to npm sencha registry with my support portal credentials, but it's impossible because my id is a email adress with an arobase and npm login doesn't seem to support it.
Then I tried to browse https://www.sencha.com/extreact but it's a 404.
As a result, while I'm not login, npm install errors with :
npm ERR! 404 Not found : @extjs/ext-react
So how to test ext-reactor ?
Your Environment
Windows 10
Exjs 6.5
npm 4.2.0

There are some things in motion that aren't quite ready yet.  In the meantime, you can use the classic-boilerplate with a local copy of the Ext JS SDK by following the instructions here: https://github.com/sencha/extjs-reactor/tree/master/packages/reactor-classic-boilerplate

Thx for your quick response !
But I ran into some troubles :
npm ERR! notarget No compatible version found<EMAIL_ADDRESS>npm ERR! notarget Valid install targets:
npm ERR! notarget 0.1.0, 0.1.1, 0.1.2, 0.1.5, 0.1.6, 0.1.7, 0.1.8, 0.1.9, 0.1.10, 0.1.12, 0.1.13, 0.2.0, 0.2.2, 0.2.3, 0.2.5, 0.2.8, 0.2.9, 0.2.10, 0.2.13, 0.2.                                     14, 0.2.15, 0.2.16

npm ERR! notarget No compatible version found<EMAIL_ADDRESS>npm ERR! notarget Valid install targets:
npm ERR! notarget 0.1.13, 0.2.0, 0.2.9

I had to change the ranges to ^0 to be able to install theses dependencies.
After that, the build succeed, but when I browse http://localhost:8081/, I have the following error :
index.js:14 Uncaught TypeError: __webpack_require__.i(...) is not a function
    at eval (index.js:14)
    at Object.<anonymous> (bundle.js?56f0957…:2147)
    at __webpack_require__ (bundle.js?56f0957…:658)
    at fn (bundle.js?56f0957…:86)
    at eval (client:3)
    at Object.<anonymous> (bundle.js?56f0957…:4226)
    at __webpack_require__ (bundle.js?56f0957…:658)
    at bundle.js?56f0957…:707
    at bundle.js?56f0957…:710

For now you should be able to fix that by switching to the v0.2.18 tag:
git checkout v0.2.18
cd packages/reactor-classic-boilerplate
npm install

1.0.0 versions will be out soon.

Having 404 when npm install
npm ERR! Darwin 16.5.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install"
npm ERR! node v6.7.0
npm ERR! npm  v3.10.3
npm ERR! code E404
npm ERR! 404 Not found : @extjs/ext-react
npm ERR! 404
npm ERR! 404  '@extjs/ext-react' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404 It was specified as a dependency of '@extjs/reactor-kitchensink'
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

@mpidev Did you check out the v0.2.18 tag?

Hmm only v0.2.17 succeed for  me, v0.2.18 failed because  @extjs/reactor-webpack-plugin 0.2.18 does not exist.

Looks like v0.2.18 never got published.  It's published now.

Thx Mark, v0.2.18 works now for classic boilerplate
FWIW, tag v0.2.17 and v0.2.18 failed for packages/reactor-material-ui-boilerplate :
$ npm start

><EMAIL_ADDRESS>start C:\node-projects\extjs-reactor\packages\reactor-material-ui-boilerplate
> webpack-dev-server --progress --colors

 10% building modules 1/1 modules 0 active
Project is running at http://localhost:8082/
webpack output is served from /
Content not from webpack is served from ./build
404s will fallback to /index.html                                                                                94% asset optimization                   building Ext JS bundle: ext => C:\node-projects\extjs-reactor\packages\reactor-material-ui-boilerplate\build\extjs
Sencha Cmd v<IP_ADDRESS>
[INF] Loading compiler context
[ERR] Cannot satisfy requirements for "modern"!
[ERR]    The following versions cannot be satisfied:
[ERR]       null: modern (No matches!)
[ERR]
[ERR] BUILD FAILED
[ERR] com.sencha.exceptions.BasicException: com.sencha.exceptions.ExVersion: Cannot resolve package requirements
[ERR]
[ERR] Total time: 0 seconds
[ERR] com.sencha.exceptions.BasicException: com.sencha.exceptions.ExVersion: Cannot resolve package requirements
Error: Error building Ext JS bundle
    at C:\node-projects\extjs-reactor\packages\reactor-material-ui-boilerplate\node_modules\@extjs\reactor-webpack-plugin\dist\index.js:209:65
    at process._tickCallback (internal/process/next_tick.js:109:7)

Did you link/copy the Ext JS SDK to packages/reactor-material-ui-boilerplate/ext?

arrghh no sorry 😭
Thx a lot, it works now after having created the symlink :

git checkout v0.2.18
is not working with ext-6.5.0 (grids are empty)
but working with ext-6.2.1
Let's us know when 1.0.0  will be ready.
Thank you.

@mpidev 1.0.0 is now available.  Please note that the reactor-boilerplate project now targets a new product, ExtReact, which is built specifically for React developers without a background in Ext JS.  Ext JS developers should use reactor-classic-boilerplate or reactor-modern-boilerplate to get up and running.  Both support Ext JS 6.5.

Thx for the update.
I close this issue since 1.0.0 is released.

I'm facing the same issue. I have the extjs standard license, but I'm unable to login into npm registry. Please advice
npm login --registry=http://npm.sencha.com --scope=@extjs
username:myemailaddress

throws error

@lingpri Only customers who purchase an ExtReact license have access to the npm registry.
Ext JS customers can download Ext JS from the Sencha support portal.  You can use Ext JS in a React application using the instructions here: https://github.com/sencha/extjs-reactor#building
Also, the extjs-reactor monorepo contains two boilerplates for using Ext JS with React:
React + Ext JS Classic Boilerplate
React + Ext JS Modern Boilerplate


It's not getting Close Friends Stories.

I had tried to use PyInstaStories to download Close Friends stories but I couldn't.
Is it a real problem or am I using it wrongly?
:smile:

It happened because I wasn't using the properly user, the script cached the first one I used then it keeps using that even when I changed. :smile:


when using"input" function, it can not show in vscode terminal

just like that, the input function is not working

another guy reported this issue


PDS4 IM Release <IP_ADDRESS>

Testing and release of LDD for IM Release <IP_ADDRESS>

I have revised PDS4_SPECLIB_IngestLDD.xml to be compatible with IM 1F00. I don't know how to re-submit it in order to address these errors. I'm attaching the file and hoping @jordanpadams or @thareUSGS will do it for me.
PDS4_SPECLIB_IngestLDD.zip

@sslavney done.
as a note, one easy way to update something that is already in Github and has a pull request created:

Towards the top of this pull request, you will see this line:

If you click the link to the branch, which in this case is named IM_release_<IP_ADDRESS>, it will take you to the branch that was actually created:

https://github.com/pds-data-dictionaries/ldd-speclib/tree/IM_release_<IP_ADDRESS>

From there, you can actually click through to your IngestLDD:

https://github.com/pds-data-dictionaries/ldd-speclib/blob/IM_release_<IP_ADDRESS>/src/PDS4_SPECLIB_IngestLDD.xml

And update the IngestLDD in your web browser:

https://github.com/pds-data-dictionaries/ldd-speclib/edit/IM_release_<IP_ADDRESS>/src/PDS4_SPECLIB_IngestLDD.xml

Then you can  Commit directly to the IM_release_<IP_ADDRESS> branch., and the system will function just like you updated it on your local machine.

Note: For future updates to the IngestLDD on the master branch you can also update in the browser. Just be sure when you commit to do  Create a new branch for this commit and start a pull request. so the automation build can kickoff.

Thank you! I did click around a little bit, but I was afraid to try anything without really understanding it. I'm learning!
From: Jordan Padams<EMAIL_ADDRESS>Sent: Friday, October 09, 2020 11:53 AM
To: pds-data-dictionaries/ldd-speclib<EMAIL_ADDRESS>Cc: Slavney, Susan<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [pds-data-dictionaries/ldd-speclib] PDS4 IM Release <IP_ADDRESS> (#2)
@sslavneyhttps://github.com/sslavney done.
as a note, one easy way to update something that is already in Github and has a pull request created:

Towards the top of this pull request, you will see this line:

[Screen Shot 2020-10-09 at 9 47 40 AM]https://user-images.githubusercontent.com/33492486/95610006-7bf1cd00-0a14-11eb-8907-debf673035de.png

If you click the link to the branch, which in this case is named IM_release_<IP_ADDRESS>, it will take you to the branch that was actually created:

https://github.com/pds-data-dictionaries/ldd-speclib/tree/IM_release_<IP_ADDRESS>

From there, you can actually click through to your IngestLDD:

https://github.com/pds-data-dictionaries/ldd-speclib/blob/IM_release_<IP_ADDRESS>/src/PDS4_SPECLIB_IngestLDD.xml

And update the IngestLDD in your web browser:

https://github.com/pds-data-dictionaries/ldd-speclib/edit/IM_release_<IP_ADDRESS>/src/PDS4_SPECLIB_IngestLDD.xml

Then you can Commit directly to the IM_release_<IP_ADDRESS> branch., and the system will function just like you updated it on your local machine.

Note: For future updates to the IngestLDD on the master branchhttps://github.com/pds-data-dictionaries/ldd-speclib/tree/master/src you can also update in the browser. Just be sure when you commit to do Create a new branch for this commit and start a pull request. so the automation build can kickoff.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/pds-data-dictionaries/ldd-speclib/pull/2#issuecomment-706291045, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJI7IEZPSMJ6OS56B3O3URTSJ45X7ANCNFSM4RBBHAXQ.

@sslavney sounds good! feel free to try anything. the beauty of Github is we can always rollback anything! (just make sure you save a copy of your work elsewhere in case we have to blow it up :-) )


can't find faster_rcnn_R_101_FPN_ft_novel1_1shot.yaml

I am trying to retrain the models following the tutorial here:
https://github.com/ucbdrive/few-shot-object-detection/blob/master/TRAIN_INST.md#fine-tuning
I am trying to use the Novel weights instead of the random weights. When I run the following command:
`python tools/train_net.py --num-gpus 8 \
    --config-file configs/PascalVOC-detection/split1/faster_rcnn_R_101_FPN_ft_novel1_1shot.yaml \
    --opts MODEL.WEIGHTS checkpoints/voc/faster_rcnn/faster_rcnn_R_101_FPN_all1/model_reset_remove.pth

I see that the config file does not exist at that location. Also the --opts flag does not exist in the code base and Hence I am manually editing the yaml files for the coresponding weights file.
WHere can I find the config files for the novel1_1shot setting?

Duplicate

Duplicate

Hi @uzair789, how'd you fix this issue? I am stuck with the same problem and I am unable to find the file anywhere. Looking forward to your reply. Thank you!


GPL-741 Should we change the +ves report file format

User story
GPL-741 | As a dev manage LIMS (Rich L) we may need to change the format of the +ves report to avoid truncating actionable data
Who are the primary contacts for this story
Rich L
Rich C
PAM
Ian J
Options
Remove samples form the report that are over 6 weeks old (Preferred by operations discussed stand up of 13th Nov)
Change the file to a text file format
Produce more than one file
Acceptance criteria
To be considered successful the solution must allow:

[ ] change file to <suggestions?>

Dependencies
Limit of MS files 1,048,576 rows (104k) : https://support.microsoft.com/en-us/office/excel-specifications-and-limits-1672b34d-7043-467e-8e27-269d656771c3
Additional context
Need for output may be superseded by New Beckman robotics package WIP Nov
+ves report at 819k rows on 13th Nov
+ves report at 602k rows on 1st Nov
+ves report at 336k rows on 13th Oct

Rich L wrote (Friday, 13 November 2020 at 16:02)
We have conflicting requirements from operations and PAM – this is my proposal
·Given that PAM are migrating to the MLWH, I’d like to change the +ves report to what operations have requested, sliding 6 week window early next week.
To ensure PAM has what it needs, if PAM is struggling to replicate the report from MLWH we will put resource on it to help. (current state tracked in RT 704189)
I don’t have a plan B today, if we can’t get MLWH to give you data you need. Open to suggestions.
My fall back was going to be google sheets for operations however has a cell limit of 4 million which we are already over with current all positives list. It certainly fails to import from a text file of 819k samples from the +ves report  (7.3M cells)
Supported by Ops (Rich C) and PAM (Rob A)

@rl15 I'm assume the window is 42 (6 * 7) days from the current day?

Discussed stand up with RCC on 19th agreed to change to 12 week window (this is in config)
Start date from date tested

tested at 17:00ish - feedback in private slack to Philip.

Post release into production;
+ves report at 834k rows on 23th Nov

Changed to 6 week window on 11th December row count 564k


add experimental rxswift extensions of siesta

There is my extension for using Siesta with RxSwift.  I'm quite new to RxSwift so the implementation may be naive. So any feedback is welcome. Especially about this questions:

Is using Driver<T> is correct for this use case?
Is it ok to use property like public var latestData: Driver<Entity<Any>?> or functions would suit better?
Should subscription on Request implicitly call start() on it?

Thanks for this! It’s the first week of classes for me, so it will be a while before I have time to give it a thorough look. Some quick thoughts:
I'm not an expert in Rx either, but I strongly suspect it's better to publish a struct snapshot of a resource's state as the ReactiveCocoa extension does instead of making each property its own separate sequence. You’ll often want to write logic that deals with multiple properties strictly in sync with each other, e.g. “if no data and loading….”

Should subscription on Request implicitly call start() on it

No. Requests are always started when Siesta returns them. You defer them using request decorators.
I don’t know about the Driver question. Somebody who knows Rx well should answer that.


updates to contrib

tiny follow ups to #189

I think developers should go the git clone route so they know what's going on. The reason for this in the first place was to help people that aren't familiar with Go and this change doesn't help with that. eg: Where the hell did go get put this stuff?

i'll acquiesce - I will reduce it to checking out of github.com/fnproject/fn instead of giving the option for a fork build. multiple examples from other people with more stars than us: https://github.com/kubernetes/kubernetes https://github.com/gin-gonic/gin https://github.com/gohugoio/hugo https://github.com/coreos/etcd/blob/master/Documentation/dl_build.md#build-the-latest-version

updated https://github.com/fnproject/cli/pull/190/commits/9e6822ab44cde1af69d3767c9fcc99a54beac52d @treeder

@rdallman the reason I included the checking out from a fork is because that's what someone external to the core team who wants to contribute (like me) is going to do most of the time.

@rdallman the reason I included the checking out from a fork is because that's what someone external to the core team who wants to contribute (like me) is going to do most of the time.

Yep, it is a problem. I guess my hope is that we can steer people towards:

clone fnproject's repo
add forked repo as a remote

I reviewed a number of go projects https://github.com/fnproject/cli/pull/190#issuecomment-370591994 and none of them explicitly mention pushing to a fork branch to submit a PR in their 'get the code and build it' step -- I do agree it seems nice not to muddle these two. If we recommend to get the code by cloning to the proper location it will avoid build errors (as experienced), at least, and then it's easy to go from there to contribute rather than having to move things around :)
there are, of course, likely a number of ways to accomplish this.

Cloning then adding remote makes the most sense. Which maybe makes the go get way easier... :)
Also, I didn't notice the follow up that already had the person cd'ing into the right dir, was just looking at the changes instead of the full file (my bad), so if you want to go back to go get, go for it.

Also, I didn't notice the follow up that already had the person cd'ing into the right dir, was just looking at the changes instead of the full file (my bad), so if you want to go back to go get, go for it.

there seems to be a mix among the community. since the cli is not build-able without make dep, clone might make more sense, since go get makes some installation assumptions.


Use spotless for formatting, update Gradle, test against Java 17

Supersedes #20
Closes #20
@BerndFarkaDyna FYI: I have updated the code to use spotless for formatting, there should be no more conflicts. I also updated to Gradle 7.3 which was released yesterday, and added Java 17 to the tested versions.

In Java versions 16 and up, some of the JVM classes required for the google java format plugin are no longer accessible by default (see https://github.com/google/google-java-format#jdk-16). To work around this, I added some conditionals to the Github workflow.


[1pt] PR: Enhancements to CatFIM, run_by_unit, and other files

Draft PR that will contain a large amount of enhancements to multiple files, primarily in CatFIM generation.

Did a full BED run, catfim run (flow-based and stage based), plus alpha tests and eval (on the BED) and it all looks great.  Just needs a little  bit more of a code review and it will be ready for approval.

Ryan or Carson should take a little peak at the changes to usgs gauges and rating curve py files.

Yeah once I've finished the branch I'll change it from draft. Waiting on
WRDS to fix a bug on their API to be able to continue testing the rating
curves changes.
On Tue, Dec 13, 2022 at 5:50 PM Rob Hanna - NOAA @.***>
wrote:

Ryan or Carson should take a little peak at the changes to usgs gauges and
rating curve py files.
—
Reply to this email directly, view it on GitHub
https://github.com/NOAA-OWP/inundation-mapping/pull/758#issuecomment-1350086949,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQS66E37R3IPR7FVRZHPQTDWNEDUXANCNFSM6AAAAAAS4ETEKM
.
You are receiving this because you were assigned.Message ID:
@.***>

--
Brad Bates
Senior Geospatial Developer
NOAA Office of Water Prediction | U.S. Department of Commerce
@.***
NOAA Affiliate, Lynker

@RyanSpies-NOAA You can go ahead and review the rating curve related scripts. Keep in mind I'll change run_by_unit.sh and gms_run_branch.sh (I'll revert to the original filenames) after you've reviewed. I am still waiting on a CatFIM job to finish, so you can hold off on reviewing that until probably tomorrow afternoon.

@RyanSpies-NOAA Not to rush you on this, but I do believe that Rob is hoping to merge this on Friday.

@CarsonPruitt-NOAA @RobHanna-NOAA please advice WRT version number. I understand there other PRs in the queue. I'll update Changelog with template version number for now.

Ran catfim for both stage based and flow based successfully over the past few days. All looks well.

Also some scripts need to produce CSVs from geopackage instead of shapefile


Text and Icons move while passing mouse pointer

When using a Board on web version, while passing the mouse over the cards, the icons and text of the cards move and shade causing difficult to read, changing identation and moving the designated icon.
Without mouse over

With mouse over

I don't know whether this effect is intended or not. To keep the space between colored border at the left and the content area, just alter the padding in the class ".task-board:hover"
from: "padding: 6px 8px 6px 0px;"
to: "padding: 6px 8px 6px 6px;"


Added an error if units provided are the wrong units

Summary Change Description
During the review of a recent PR (#622), it was decided the stripping the units with only a warning was too risky, so I proposed in #666 to only strip "expected" units and otherwise issue an error that stops loading, so that's what this PR does.
While I was at it looking at units, I also added units to the Tracer Concentrations in the web and download templates.  They were already in the FCirc templates, but not the peak groups or peak data, which I believe was an oversight.  I'd gone to look at the website to get the expected tracer concentration units and was surprised they weren't there...
Affected Issue Numbers

Resolves #666

Code Review Notes
Open to suggestions on strictness/flexibility and where to store the expected units that's not too "hard-coded" like it is now.
Checklist

[x] Changes have been added to the Unreleased section in the changelog.md.
[x] All issue requirements satisfied (or no linked issues)
[x] Linting passes.
[x] Migrations created & committed (or no model changes)
Tests

[x] Tests implemented (or no code changes)
[x] All tests pass
[x] All example load tests pass (remotely) (or their failures predated and are unrelated to this branch)

I like the additional functionality, though I don't think there is a need for a warning when expected units are found and stripped and the data is loaded.

I would have agreed with you had I not encountered a case where the warning revealed a problem.  In the cold exposure data, there was a subset of rows where units had been provided.  I think they were correct units, but Michael pointed out that another researcher had added them, but that the numbers were incorrect.
Units are not officially "allowed", which is why I originally made it a warning.  But I'm amenable to allowing "correct/supported" units and removing the warning.  We would have to update the docs WRT the documented format of the columns in the spreadsheet template.

Re-requesting review @lparsons. I added some points of discussion to your blocking issue. Let me know if I've changed your mind.

In my opinion, we often interpret what they enter (e.g. dates, compounds, etc.) and store things as appropriate in the database, not as verbatim strings. If you'd like to leave it, that's fine, but let's try to make it clear that we did, in fact, store the value they provided assuming the provided unit. As it reads right now, it almost seems like the data wasn't valid and/or stored.


Remove geocoding completely!

Currently we are geocoding venues in our test suite through google's API.
There are several ways to fix this.
We can stub geocoding in test everywhere.
Or maybe we don't need to geocode venues automatically.

I am thinking now we should remove geocoding completely. Yes, sometimes it's convenient - but it's not only slow but also inaccurate, and the inaccuracy causes confusion.
How about instead, we display a modal "Pick your school"?

Should we rethink how we're handling different schools, since both SF and Cville are having classes online? It seems like a lot of people (especially in other cities) may be missing out on good learning opportunities by being forced to choose a school. At the same time, the bulk of our students are still physically coming to classes and shouldn't have to deal with spam about classes from another part of the country/world unless they explicitly want them.

Yes, we should allow people to pick and choose which schools they want to subscribe to.

I think the geocoding is being inaccurate because the value we use with the near method is too high. The distance between SF and Cville is about 2800 miles, but we are passing 5000 miles into near to find a school for a user. As currently set up, the school assigned would be dependent on how schools are sorted (as opposed to which school is closer to a user) because both schools would be within range of anywhere in the continental US. I think a parameter of 1400 miles to the near method would make the geocoder work as expected.
If we do decide to take out geocoding completely, it seems to me that the drop down button in the header would suffice for users to choose their school. If the user is a guest, then we can store that school in a cookie (in addition to the session).
I think, for now, we should try the geocoding with the 1400 miles and if it continues to be unreliable, then there would be no need to keep it.

Sounds good to me. Thanks Donald!

@donaldali can we close this?

I got a report from Nene that when she pulled up RS on her phone last week, it opened to the cville site. I don't know if this was due to cookies being set from a previous time but I worry there might still be an issue. Can anyone in SF reproduce?

On Jun 9, 2015, at 5:08 PM, Brad Johnson<EMAIL_ADDRESS>wrote:
@donaldali can we close this?
—
Reply to this email directly or view it on GitHub.

I feel like it's working better in SF with Donald's patch. How about out on the east coast, in a clean browser session, does the app show you Cville?

We definitely at least should set a timeout for the geocoding < ~10 seconds, because unicorn times out at 15 seconds.

if google doesn't respond within 1 second for geocoding, it's probably an issue, so it'd be better to retry once or twice and then fail fast, rather than waiting for it to time out.

I'm not sure I understand. Right now we're not timing out the google call, google isn't failing it's just taking longer than 15s to respond. So I propose we do timeout the google call.

If the google call is really taking longer than 15s to respond, then
something's wrong. This should be a fast lookup, so I'd consider anything
longer than 500ms to be an issue that we should mitigate.
On Thu, Oct 8, 2015 at 5:05 PM, Gabe Kopley<EMAIL_ADDRESS>wrote:

I'm not sure I understand. Right now we're not timing out the google call,
google isn't failing it's just taking longer than 15s to respond. So I
propose we do timeout the google call.
—
Reply to this email directly or view it on GitHub
https://github.com/rails-school/school/issues/59#issuecomment-146721085.

Sounds good.


feat(ast): remove explicit untagged marker on enums

This assumes that any enums with exactly one field in each variant are untagged, and they're tagged otherwise.

#6915  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ottomated and the rest of your teammates on  Graphite

Merge activity

Oct 26, 4:21 AM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.


The padding for IconButton and ListItem are absent for @material-ui/core 5.0.0-alpha.21

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

Expected Behavior 🤔

Steps to Reproduce 🕹

Steps:
Upgrade @material-ui/core from 5.0.0-alpha.20 to 5.0.0-alpha.21
Context 🔦

Your Environment 🌎

`npx @material-ui/envinfo`

Please provide a code-sandbox reproducing the issue, thanks.

Got the same problem,
It seems emotion style loaded in the wrong order and override the jss style,

Try yarn start on my project,
https://github.com/xs9627/feedpop/tree/next_21

Duplicate of https://github.com/mui-org/material-ui/issues/24186
You need to use <StylesProvider injectFirst> from @material-ui/core in order for the emotion styles to be injected first in the head. See https://next.material-ui.com/guides/interoperability/#css-injection-order for more info.

Duplicate of #24109

Duplicate of #24186
You need to use <StylesProvider injectFirst> from @material-ui/core in order for the emotion styles to be injected first in the head. See https://next.material-ui.com/guides/interoperability/#css-injection-order for more info.

After I add <StylesProvider injectFirst> the result is still the same

Duplicate of #24186
You need to use <StylesProvider injectFirst> from @material-ui/core in order for the emotion styles to be injected first in the head. See https://next.material-ui.com/guides/interoperability/#css-injection-order for more info.

After I add <StylesProvider injectFirst> the result is still the same

It should work. Make sure the import to the StylesProvider is correct. If you provide codesandbox I can take a look.

It should work. Make sure the import to the StylesProvider is correct. If you provide codesandbox I can take a look.


"Găujani", "Goia" are listed in the drop-down menu

Description:
When user writes "Găujani" and "Goia" the locations appear in the drop-down menu next to the comune and the county witch is a part according to the law
Precondition:
The website is up an running.

Step 1
Write in the search bar "Găujani"

Expected results
The location appears in the drop-down menu as "Sat Găujani, ARGEȘ (Ungheni)"

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Write in the search bar "Goia"

Expected results
The location appears in the drop-down menu as "Sat Goia, ARGEȘ (Ungheni)"