* Add `platform-version` field to `daml.yaml`
This PR adds the `platform-version` field to `daml.yaml`. Based on the
approach agreed upon in #6558, the logic for this all sits in
`daml-helper` and there are no changes to the assistant.
The details of how the logic work are in a comment so I’m not going to
repeat them here but the commands that are affected are:
- `daml sandbox`
- `daml sandbox-classic`
- `daml json-api`
- `daml start` (but only for sandbox and the JSON API, not for
Navigator or anything else)
For tests, I’ve added a test to the compat workspace that installs two
SDKs simultaneously and tries out various combinations and verifies
that we get the correct version. Open to other ideas for testing this
but that seemed like the most sensible option that actually tests what
we run.
changelog_begin
- [DAML Assistant] You can now specify the version of Sandbox and the
JSON API independently of your SDK version by setting
``platform-version`` in your ``daml.yaml``. This is useful if you
are deploying to a ledger that is running components from a
different SDK version. See
https://docs.daml.com/tools/assistant.html#project-config-file-daml-yaml
for details.
changelog_end
* Run platform-version tests
changelog_begin
changelog_end
* Fix tag globbing
changelog_begin
changelog_end
* fmt
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
* Try to fix env vars
changelog_begin
changelog_end
* Remove hardcoded references to 1.2.0
changelog_begin
changelog_end
* Rephrase doc comment
changelog_begin
changelog_end
* get things to compile
changelog_begin
changelog_end
* maybe fix things for realz
changelog_begin
changelog_end
* Remove debugging output
changelog_begin
changelog_end
* Get angry at windows
changelog_begin
changelog_end
* why is windows
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
* Ledger API Test Tool: deprecate unneeded tests and options
Furthermore, now all active tests are now run be default without needing
to specify --all-tests. The scheduler makes sure to run non-isolated
tests last (and sequentially).
Fixes#3747Fixes#6518
A bit of historical context: tests in the Ledger API Test Tool used to
be the sandbox integration tests. As part of the Ledger API Test Tool
project, those tests have been ported one-to-one, with little review of
those same tests.
Examining the tests that cause #3747, it became evident that those tests
were originally put in place to verify that an isolated sandbox spun up
for a single test could withstand a number of commands slightly lower
than what at the time was the hard-coded back-pressure threshold. Hence,
implementing back-pressure on the Ledger API Test Tool would have
basically negated the usefulness of those tests. Furthermore, those
tests can be easily passed by simply raising the back-pressure
threshold. As such, they do not convey any meaningful information for
the DAML ledger implementor. This means we are retiring those tests. The
tests will be nominally kept in for a deprecation period to not break
existing build scripts, but running them explicitly will simply show
them as skipped. The documentation has been updated with the information
necessary to users to deal with retired tests.
Since all tests are now run by default --all-tests is being deprecated.
--load-scale-factor is also deprecated as it was used only by
TransactionScaleIT.
changelog_begin
[Ledger API Test Tool] The LotsOfPartiesIT and TransactionScaleIT test
suite have been deemed not providing relevant signal to DAML ledger
implementers and have been retired. The tests will be nominally kept in
but will be skipped while they are in a deprecation period. You are
advised to remove explicit references to those tests before they are
fully removed.
[Ledger API Test Tool] All tests are now run by default. The --all-tests
option is now ineffective and deprecated. You are advised to remove its
usages from your build scripts. Non-isolated tests that could affect the
global state of the ledger and interfere with other tests are now
automatically scheduled by the test tool to run sequentially at the end
of the run.
[Ledger API Test Tool] The --load-scale-factor option is now unused and
deprecated. You are advised to remove its usages from your build
scripts.
changelog_end
* Add test for deprecated CLI options
* Address https://github.com/digital-asset/daml/pull/6651#discussion_r452100158
* Address https://github.com/digital-asset/daml/pull/6651#discussion_r452126405
* Address https://github.com/digital-asset/daml/pull/6651#discussion_r452143811
* Address test failures
Added a new section in the cheat-sheet for basic DAML concepts (there's anotehr PR for it). This PR links the cheat-sheet to the GSG. This was a requirement that came out of the user tests where testers said that they would like to have a quick overview of the most important DAML concepts explained (they found jumping through the glossary and the rest of the docs too complicated).
CHANGELOG_BEGIN
CHANGELOG_END
* Support multiple auth tokens in DAML Script
This piggy backs on top of the already existing --participant-config
feature. While you can argue that it might be slightly confusing that
you have to specify the same participant twice to specify different
auth tokens, I think this actually makes sense: In an ideal
world (ignoring any performance issues) you have one participant per
party anyway and one connection per participant specified in the
config file still seems like a very reasonable model.
changelog_begin
- [DAML Script] You can now use DAML Script with multiple auth
tokens. This is particularly useful if you are working with the JSON
API where you can only have one party per token or with an IAM that
only provides single-party tokens. The tokens are specified in the
participant configuration passed via `--participant-config` in a new
``access_token`` field. The existing `--acess-token-file` flag is still supported if you want to use the same token for all connections. See
https://docs.daml.com/daml-script/index.html#running-daml-script-against-authenticated-ledgers
for more details.
changelog_end
* I will never understand rst
changelog_begin
changelog_end
Noobs had a problem running yarn install v1.12.3
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.40s. second time around when they^ve changed the code. Simply put they would way too often (almost alqways) forget to include when calling yarn install v1.12.3
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.34s.. This would be a very simple workaround that woould lead to them being aware from the very first step that there's the parameter that needs to be called.
CHANGELOG_BEGIN
CHANGELOG_END
This is the final bit extracted from #6314. This PR adds the capability
to filter individual test cases (for either inclusion or exclusion)
while being completely backwards compatible. It also introduces a new
cli option, `--list-all`, to list all test cases, keeping the behaviour
of the existing `--list` option unchanged, i.e. only print test suites.
Unlike #6314, this is still building upon the idea of defining test
suites as maps, preserving the known-good order of tests and thereby not
introducing flakiness into our builds.
CHANGELOG_BEGIN
- [Ledger API Test Tool] ``--exclude`` and ``--include`` now match the
full test name as a prefix, rather than just suite names. Test name is
built by combining the suite name with a test identifier, so this change
should be fully backwards compatible. Run with ``--list-all`` to list
all tests (as opposed to just the test suites with ``--list``).
CHANGELOG_END
This integrates the time service into DAML script thereby covering the
main piece of scenarios that was missing from DAML script.
This PR does two things (they are very related and doing them together
makes it much easier to test):
1. It “fixes” `getTime` to return the ledger time in static mode by
querying the ledger time service instead of defaulting to the Unix
epoch which is pretty useless and I would consider the old behavior
a bug. We keep the old behavior via the JSON API since there is no
time service.
2. It adds `setTime` to set the ledger time via the time service. This
is only supported in static time mode (sadbonx and other ledgers do
not expose the time service in wallclock mode because changing time
makes it not wallclock) or via the JSON API (no time service).
fixes#6220
changelog_begin
- [DAML Script] DAML Script’s `getTime` now correctly handles time
changes in static time mode and returns the current time by querying
the time service rather than defaulting to the Unix epoch. Note that
when run via the JSON API, it still returns the Unix epoch.
- [DAML Script] Add `setTime` to DAML Script which sets the ledger
time via the ledger API time service. Note that this is only
supported when running over gRPC in static time mode.
changelog_end
In #6378, I erroneously removed what I (and two other people who looked
at the document) thought was a typo. It turns out it wasn't, but I still
believe the existing form was a bit confusing. This is my attempt at
reintroducing and clarifying the original meaning.
CHANGELOG_BEGIN
CHANGELOG_END
* PATH instruction settings
We've been getting the same feedback now for two users tests that users have somewhat hard time figuring out how to set the variable. Also tonce they download the SDK the somehow miss ghe message/instructions that they need to add to variable
CHANGELOG_BEGIN
CHANGELOG_END
* Added own instructions for setting the variables
* Added the necessary headers
* Fixed the title underline too short
* Update docs/source/getting-started/path-variables.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update docs/source/getting-started/path-variables.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update docs/source/getting-started/path-variables.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update docs/source/getting-started/installation.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Addressing Moritz's and Samir's feedback
* Single and double quotes fix
* Update docs/source/getting-started/installation.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update docs/source/getting-started/path-variables.rst
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Restarting the computer wording fix
* Bash/shell wording fix
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
In user tets users complained that they were missing an overview of how all the components in the GSG are connected. This is a very simple fix addressing it: the 'App Architecture' and 'Your First Feature' sections are moved to be on the same level as 'Build Your App'
CHANGELOG_BEGIN
CHANGELOG_END
After going through the GSG users were not sure what are the next steps. Adding the next steps at the end of the GSG is an easy fix for this,
CHANGELOG_BEGIN
CHANGELOG_END
* Reorder sentence to clarify meaning
* Fix word ordering
* Add articles to clarify sentence.
* Fix italicize formatting
* Clarify pasting command
* A few more propositions for clarification
* Spelling and clarification nit
* More propositions for clarity
* Remove redundant words
* Fix word ordering
* More propositions
* Specification for clarity
* Remove weird transition
* Extend stars in header to match text.
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Better English
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
CHANGELOG_BEGIN
- [JSON API] The WebSocket endpoints ``/v1/stream/query`` and ``/v1/stream/fetch`` are now
stable; these endpoints in SDK v1.0.0 are fully compatible with this first officially
stable version.
See `issue #6152 <https://github.com/digital-asset/daml/pull/6152>`_.
CHANGELOG_END
* Add a module-prefixes field to rename all modules in a pkg
This PR adds a `module-prefixes` field to `daml.yaml` a a shorthand
for specifying a `--package` flag that renames all modules in a
package to have the same prefix.
The docs are updated to describe how you can use this field and there
is a test case that makes sure it works.
fixes#4948
changelog_begin
- [DAML Compiler] You can now use the new ``module-prefixes`` field in
``daml.yaml`` to add a prefix to all modules from a dependency. This
is particularly useful for handling colliding module names during
upgrades. See
https://docs.daml.com/daml/reference/packages.html#handling-module-name-collisions
for more information.
changelog_end
* Update compiler/damlc/daml-opts/daml-opts-types/DA/Daml/Options/Packaging/Metadata.hs
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* Improve docs and fix broken suggestion
changelog_begin
changelog_end
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* ADD: Change most Slack references to forum references where appropriate
CHANGELOG_BEGIN
Replace references to Slack with references to discuss.daml.com
CHANGELOG_END
* ADD: Change issue template support link from SO to forum
* ADD: Add back Slack links
The `da` tool has not existed for a while now and it's unlikely any new
user will need to know about the upgrade path. I think starting from
1.2.0 it makes sense not to have that documenation around anymore.
Note that we do have references to the upgrade page in the release
notes, so leaving them as is would break building the documentation. My
preference would have been to turn those references into "external"
links to the relevant version, but unfortunately, these are versions
(`0.12.15` and `0.12.18`) that, for various reasons, we cannot build
anymore and do not have in pre-built form. I have therefore decided to
change the links in the release notes to link to the latest existing
version of that page (which is pretty much what it already did), i.e.
specifically link to `1.1.1`.
CHANGELOG_BEGIN
CHANGELOG_END
* Add JSON output to `damlc inspect-dar`
fixes#3117, fixes#5563
This PR adds a `--json` flag to `damlc inspect-dar` that does pretty
much what you expect. So far it mainly exposes the same information
that you already got from `inspect-dar` but it’s easy to add more as
needed.
I’ve also finally added some documentation for `inspect-dar`.
changelog_begin
- [DAML Compiler] ``damlc inspect-dar`` now has a `--json`` flag to
produce machine-readable output. See
https://docs.daml.com/daml/reference/packages.html#inspecting-dars
for more information.
changelog_end
* Sort packages in human-readable output
changelog_begin
changelog_end
* Update docs/source/daml/reference/packages.rst
Co-authored-by: Rohan Jacob-Rao <rohanjr@gmail.com>
Co-authored-by: Rohan Jacob-Rao <rohanjr@gmail.com>
At least for now we still somewhat pretend to have a linear version
history so we want to include this in future releases.
changelog_begin
changelog_end
* add GenMap to the "all types" test generators
* report bad GenMap format with DeserializationError, not MatchError
* document GenMap JSON
* notes on missing features
* enable -Xsource:2.13 in transaction
* make an Order instance for Value resolvable, but unimplemented
* use the skeleton from SValue ordering to make a Value ordering skeleton
* add Party Order
* add Order instance for SortedLookupList
* add Order for FrontStack, deriving everything
* factor the Order lookup, and tie a knot in the recursive Value instances
* we're going to need this Iterator thing again
* replacing Order#contramap with version that supports equalIsNatural
* use new equalBy, orderBy for FrontStack, SortedLookupList, ImmArray
* _2 comparator, upgrade Name Equal to an Order
* incorporate lookup for enums, variants into Value order; record/struct cases
* Enum/Variant comparison
* looking up the singleton implicitly won't work for non-`object`s, alas
* test Order laws for values of all primitive types
* test Order laws for record and variant types
* test Order laws for enum types
* test that enum strings are not compared
* use checkLaws for Value Equal as well
* test that enums match order to constructor rank
* factor genAddend and genAddendNoListMap
* reintroduce Order for TypedValueGenerators
* more addend order
* record, variant order cases
* record cons order
* deriving Order while decoding from JSON
* make ApiCodecCompressed's Cid codec based on the typeclass
* test how the Value ordering and the underlying projected value orderings line up
- hint: they don't, yet
- this is also a template for how we'll check the fidelity with SValue
ordering
* test how the Value ordering and SValue ordering line up
- hint: they don't, yet
* typed Arbitrarys have access to Order
* produce proper ValueGenMap
* inj requires Order, sometimes
- we encode this as "all the time" but there is a type-level unification
approach to remove this requirement in some cases
* make inj a function
* test that order doesn't matter for JSON decoder
* use Utf8 order for TVG text; don't pretend that base equal works
* sort JSON GenMaps, and check for duplicates
* make injarb use IntroCtx
* remove stray import
* Order instances for Bytes, Hash, AbsoluteContractId
* require Order[Cid] to decode JSON to LF values
* clean up map reordering test
* remove unused Instant instance
* fake Order instance no longer needed, valid instance defined
* test parity of global AbsoluteContractId order and SContractId order
* bazel fmt
* test AbsoluteContractId Order lawfulness
* test duplicate key detection
CHANGELOG_BEGIN
- [JSON API] Prepare full support for the planned GenMap primitive type.
See `issue #5031 <https://github.com/digital-asset/daml/issues/5031>`_.
CHANGELOG_END
