* Fix daml build for usernames with spaces
This PR fixes two issues caused by having spaces in your username:
1. On Windows, we need to quote the path to the daml binary in the
batch wrapper (quotes are not valid in usernames, so no need to worry
about escaping them).
2. Invoking ghc-pkg via callCommand broke since shells are
terrible. Luckily, we can easily get away with just using callProcess
here.
* Update compiler/damlc/lib/DA/Cli/Damlc.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* language: put hash in package directories
We put the package id of the main dalf of a package into the directory
names, where we store the files of that package in the package database.
This way we make sure that two equally named packages don't overwrite
their dependencies and files.
* Supporting producing sdist tarballs for the HS ledger bindings
The README.md has an explanation for how you can use this.
This should hopefully allow others to experiment with the bindings.
Currently, if you do `daml init foo` and there's a file `foo/Main.daml`,
you'd end up with a file `foo/daml.yaml` whose `source` entry is
`foo/Main.daml`when it should actually just be `Main.daml`.
This PR fixes this problem.
* daml deploy: first version
* fix build: replace callCommand with runProcess_
* abstract/share: doBuild, getDarPath
* hide deploy command for now
* make sandbox port configurable for both deploy & start daml-helper commands
fixes#2142
It turns out that typed-process has the behavior we want so rather
than rolling our own version of `withCreateProcess`, I just switched
to that.
extractTarball tries to restore the ownership stored in the
tarball. This goes wrong when the tarball is fetched from CI since the
uid/gid might not exist locally.
* Bazel: 0.24.0 -> 0.27.0
* Update rules_haskell for Bazel 0.27 compatibility
* Update bazel-deps and bazel-watcher
* Windows escape JVM flags
* load commands at top of .bzl file
Bazel 0.27 no longer allows load commands that are not at the beginning
of the file.
* Update Bazel rules
* subpackage boundary
* native is not defined in BUILD files
* yarn: @bazel/hide-bazel-files
Seems to be required since latest rules_nodejs version. Otherwise, yarn
fails with errors about existing BUILD or BUILD.bazel files.
* grpc-java plugin visibility
* Update fat_cc_library
* Nix Python3 toolchain
* Iteration over depset
* dev_env_package: Create symlinks one level deeper
To prevent symlinking the BUILD file as well. The nested BUILD file
confuses Bazel as of 0.27 and rules_nodejs cannot find the node
executable anymore.
* Update rules_nodejs
* Add managed_directories for node_modules
* hie-bios: Extract bazel-genfiles from bazel info
Bazel 0.27 changed the genfiles location which breaks the hie-core test
on macOS.
* update cc_wrapper to Bazel 0.27
* bazel info -> bazel info bazel-genfiles
* Fix typo in BUILD
Co-Authored-By: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* language: upgades: generate upgade code from dalfs
This switches the `migrate` command to read dalf files instead source to
generate upgrade code. The dalf files are read, data types are converted
back to haskell source, and from this we can generate generic instances
again.
There are two known issues that we want to address next:
- Duplicate generic instance definitions will make the build fail.
I.e this only works for data declarations that have no generic
instances
- Data declarations of the form `data Foo = Foo ()` can not be
converted back to haskell source.
* Update rules_haskell and static GHC
Remove patches that have been upstreamed or are no longer required.
Update still required patches to match the new rules_haskell version.
Previously we patched rules_haskell to coerce GHC into using static
Haskell libraries in most places. In particular we moved hs-libraries
entries into extra-libraries entries in the package configuration files.
A much cleaner approach is to compile GHC with a static RTS, then GHC
will by itself choose to load static Haskell libraries.
* Remove haskell_cc_import
* da-hs-daml-cli -> daml-cli
* da-hs-damlc-app -> damlc-app
* windows: hanging GRPC FFI call problem resolution
* windows: fix visual test
* windows: enabled back again some of disabled daml-assitant tests
* marking daml_ghc_integration_test as large
language: upgrades: dont derive generics for data types having the instances already
We only derive generic instances on the fly for data types that don't
have them already.
* Add support for haskell_repl targets in da-ghci
* Change default target
* Revert newline loss.
* bazel fetch before bazel query
* Make a top level repl target the default.
* Add da_haskell_repl dependency in //BUILD
* Fix syntax error
* Fix bazel formatting...
* Rename DamlHelper modules to make //:repl work
* DamlHelper -> DamlHelper.Run
* Update the import in DamlHelper.Main
* Fix bazel rules again
* Update DamlHelper import in integration-tests
* language: generate module containing generic instances
The migrate command generates generic instances of data types and puts
them in a separate module. For now this only works if the data type
doesn't have a generic instance already, we'll deal with this case in
the next PR.
* Add --install-assistant option
* Better doc on iActivate
* Determine whether to install assistant based on new flag
* Fix logic and update install warning
* Remove --activate from install.sh
* Add missing ]
* Change deprecation warning.
* Add release notes for new option.
* Update help text for install-assistant
* Fix release notes
* language: feature: initial implementation of a 'migrate' command
We add a 'migrate' command to daml assistant that generates a project
that allows to migrate contract instances from package1 to package2.
This first version reads both package1 and package2 from source. As a
next step we read only the dalfs from package1, because it might have
been created with a different compiler.
* Simplify daml version output
* Make sure project version is really from daml.yaml
* Calculate latest version more thoroughly.
* Only show latest version if available
* Add test case for damlc test-files
* Separate damlc test-files from damlc test
* Fix rules_daml/daml.bzl daml_test
* damlc test-files --> damlc test --files
The project options are still relevant for the --files case, as it may
be necessary to change into the project root directory in order to
locate the project package database.
This was already possible before via the DAML_PROJECT environment
variable but for users that want to call damlc directly, e.g., via
damlc.jar a CLI flag can be more convenient.
* List all available versions.
* Add --all flag in daml version
* Save version list to cache
* Update version cacheing logic.
* Linting error
* PR revisions.
* Update release notes.
* Update daml-assistant/src/DAML/Assistant/Version.hs
* Update docs/source/support/release-notes.rst
Co-Authored-By: Beth Aitman <bethaitman@users.noreply.github.com>
* no var no problem
further refactor
introduced InfraState
a bit less vars
encapsulating closes
SandboxServer starts automatically
rebase fixup
collecting state into a single object
some cleanup
removing exposed materializer
LedgerBackend is closed in SandboxServer
changed ownership of Ledger
fixing perf tests
fixing some compile errors
formatting
removing unused method
fixing integration test to use correct dar file
fixing issue with PostgresFixture and SandboxResource
Fix integration tests on Windows
* fixing rebase artifacts
* Add an option to not modify PATH in daml install --activate
This is particularly useful in test suites where you install to a
temporary directory that should not be added to the registry.
* Use yes/no/auto
* Make check more robust
* Separate version logic out of DAML.Assistant.Env.
* Refactoring some of the exception handling.
* Update daml version command.
* Uncommit linting atrocity.
* Started working on daml init.
* Implement daml init.
* Nicer messages and nicer field generation.
* Cleaning up a duped definition.
* Review revisions
* Catch all synchronous exceptions when making network requests.
* Wrap all of getLatestVersion.
* wrapErr wraps sync exceptions as well.
* Pass through exit codes.
* Add two failing getDispatchEnv tests.
* Fix getDispatchEnv idempotency.
* Fix new test formatting.
* Make getDamlAssistantPath look in env first.
* Fix daml env var overriding.
* Test all the Nothing cases of env var dispatching.
* Fix dispatchEnv and getDamlEnv for Nothings.
* Add hlint rule to avoid future setEnv debacles.
* Fix other uses of setEnv.
* Fix type error.
* Fix reviewer comments
* setEnv comment
* Do not ask user to install when they are already running the install command.
* Avoid looking at unecessary information when doing daml install.
* Update daml-assistant/exe/DAML/Assistant.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Remove unnecessary import.
* Move code shared between lib and tests to a DAML assistant library
Previously we were compiling the same code twice, once for the binary
and once for the test suite.
* Move tests and binary to separate directories
The lack of sandboxing on Windows in combination with
-Wmissing-home-modules breaks our Windows build otherwise.
* Auto-install requested SDK versions.
* Avoid crashing if the requested sdk is missing (and auto-install is off).
* swap the default and the auto install
* Suggestions
* Explain why install messages go to stderr in one case.
* Lint error
* Determin running daml assistant version.
* Auto-update daml whenever assistant SDK version is less than auto-installed version.
This PR changes `daml studio` to automatically install newer SDK
versions by default. The behavior can be overwritten to either force
the current SDK version (which should only be necessary if we break
backwards compatibility) or to not touch existing installations at all.
There were two issues in `daml studio`:
1. We need to use `shell` instead of `proc` to launch VSCode.
2. Creating symlinks requires admin privileges on Windows so instead
we just copy the directory.
Note that `daml studio` will not install or upgrade the extension if
it is already installed (this fact is unchanged by this PR). We should
change this to upgrade to newer versions by default (and add an option
to not do this) but I’ll leave that for a separate PR.
* language: change default output dir of `package` command
This changes the default output path of the `package` and `build`
command from the project root to the `dist` directory.
* fixed daml-assistant integration tests
When echo is enabled (which is the default), the IDE can get really
confused since it tries to interpret the commands as LSP messages
which obviously fails.
Apart from the fact that START was missing the windows title argument
it launches a new terminal window and then exits immediately (the
terminal windows is closed immediately as well) so it seems like the
wrong thing to use. Just calling the executable directly seems to work
fine both in cmd.exe and in powershell on my Windows 10 VM so
hopefully this is reasonably robust.
* Build project automatically in "daml start"
This gives us an interface that more closely resembles "da start" and
is also more convenient for users.
* Make it clear what DamlAssistantPath points to
* Add SDK version check before download.
* Get latest version from github, not URL directly.
* Prune unused parts of the Github API.
* Refactor AssetName out.
* Reorder the github module.
* Use redirect instead of GitHub API to get latest stable version.
* Do not limit number of redirects.
* Fix bazel rule
* Actually fix build rule
The codegen integration tests assume a specific location atm so we
need to specify that explicitely (eventually we might want to change
them to use the default location but not for now). The reason why we
didn’t catch this before merging the package-new command is that the
PR was not rebased on top of the changes that added the codegen
integration tests.
* language: new package command for damlc
The (internal) package-new command reads all information from the
daml.yaml file of a DAML project and also creates the .conf file for the
package database and packs it with the dar.
* Add buildifier targets.
The tool allows to check and format BUILD files in the repo.
To check if files are well formatted, run:
bazel run //:buildifier
To fix badly-formatted files run:
bazel run //:buildifier-fix
* Cleanup dade-copyright-headers formatting.
* Fix dade-copyright-headers on files with just the copyright.
* Run buildifier automatically on CI via 'fmt.sh'.
* Reformat all BUILD files with buildifier.
Excludes autogenerated Bazel files.
The `daml-assistant` BUILD file was missing an `src_strip_prefix` field
and abtracted away the dependency list for two of its targets. The
latter is not strictly needed and may lead to too many dependencies
being specified for the targets.
* Use global SDK version for release tarballs.
* Use semver for sdk versions.
* Update daml-assistant/BUILD.bazel
* Code comments pt 1
* Switch to lens
* Update daml-assistant/BUILD.bazel
Docker causes a few issues for us here which imho outweigh the
benefits for us atm:
1. It is quite slow since we have to rebuild the image everytime. We
could fix this by caching the image somewhere but even that is
somewhat annoying since Azure does not provide local caches so we
would have to push the image to some external service and fetch it
everytime which is still somewhat slow.
2. It does not work on MacOS (even if you have docker on MacOS it is
not going to work since you will try to install the MacOS release
tarball in a Linux docker container).
On the other hand, DAML assistant allows us to specify the
installation directory and we get a fairly clean environment on CI so
the additional isolation we get from Docker is not that important for us.
* Make daml-asisstant forward --help as intended.
* Refactor command-line parser in daml-assistant.
* Fix issues with daml-assistant CLI.
* Misalign things for Martin.
