data-dependencies fail if dar filename/project name has '_' character

[ashfaq-shaik]

Project 1, has a series of templates that are to be imported into Project 2 Project 1's daml.yaml config is as below

sdk-version: 1.8.1
name: petri_data_objects
source: daml
init-script: Main:setup
parties:
  - Alice
  - Bob
version: 1.0.0
dependencies:
  - daml-prim
  - daml-stdlib
  - daml-script
sandbox-options:
  - --wall-clock-time

When project 1 is built, it gives petri_data_objects-1.0.0.dar

above dar is being added to project 2 via daml.yaml. config below

sdk-version: 1.8.1
name: petri_logic
source: daml
init-script: Main:setup
parties:
  - Alice
  - Bob
version: 1.0.0
dependencies:
  - daml-prim
  - daml-stdlib
  - daml-script
data-dependencies:
  - ../petri_data_objects/.daml/dist/petri_data_objects-1.0.0.dar
sandbox-options:
  - --wall-clock-time

when I build Project 2. I receive the error below

ghc-pkg: 0: Parse of field '
unexpected '_'
expecting "-", white space or end of input

petri_data_objects
' failed.
damlc: callProcess: /Users/yukikaze/.daml/sdk/1.8.1/damlc/resources/ghc-pkg "recache" "--global-package-db=.daml/package-database/1.8/package.conf.d" "--expand-pkgroot" (exit 1): failed

[cocreature]

Hi @ashfaq-shaik, this is unfortunately expected. In SDK 1.9.0, you get a much nicer error message for this:

WARNING: Package names should have the format ^[A-Za-z][A-Za-z0-9]*(\-[A-Za-z][A-Za-z0-9]*)*$.
You may be able to compile packages with different formats, but you will not be able to
use them as dependencies in other projects. Unsupported package names or versions may
start causing compilation errors without warning.

This is unfortunately a limitation of some underlying libraries so at the moment, we cannot change that and you have to respect the restrictions on project names.

[ashfaq-shaik]

Understood.

In that case, may I suggest having a lint/build rule to not allow these characters in the project name. maybe the build should fail if '_' or other non compliant characters are used in the project name. Avoiding this at the original project build would weed out any un needed sideeffects when importing into a different project.

My suggestion, this should not be allowed You may be able to compile packages with different formats, but you will not be able to use them as dependencies in other projects. . Rather you should not allow people to compile/build packages if the project name is non-compliant. This would reduce a lot a friction and troubleshooting

[cocreature]

I do agree with you here. Note that the warning will be omitted when building the project not when you depend on it. The only reason it’s not an error is for backwards compatibility. At least for things like demos, not being able to depend on it doesn’t matter much so we only went for a warning. I expect, this will turn into an error at some point in the future.

[cocreature]

Closing since we already warn and we keep it a warning for backwards compat.