enable compilation / usage of contracts that have includes of other files

[marc0olo]

I am not sure if this is supported yet. currently I guess I have to either include everything in one file or create a separate file with contract interface only to be able to interact with the contract.

[marc0olo]

ok I think we should encourage usage of ACI for this. but it's also not easy to figure that one out for newcomers. struggling myself again with this topic

[marc0olo]

had to rename encoded_aci to encodedAci and external_encoded_aci to externalEncodedAci due to errors. I tried to use the response provided by http compiler.

how should the ACI be generated @davidyuk ? seems to be very inconvenient right now

[marc0olo]

I am mainly talking about static calls only right now.

for deployments we should be able to handle the includes and fileSystem accordingly

[davidyuk]

I am not sure if this is supported yet

It is not supported

how should the ACI be generated

Currently it is expected to use compiler from sdk

aepp-cli-js/test/contract.js

Lines 52 to 55 in 5d0ef4b

	await fs.outputJson(
	contractAciFile,
	await sdk.compilerApi.generateACI({ code: testContractSource, options: {} }),
	);

I think I can reuse getFilesystem from aeproject, later cli compiler can be used after implementing aeternity/aepp-sdk-js#1668

[marc0olo]

I think I can reuse getFilesystem from aeproject, later cli compiler can be used after implementing aeternity/aepp-sdk-js#1668

let's go this route for now, but we somehow need to provide a way to compile with includes.

I will try to get some attention for aeternity/aesophia_cli#66 and aeternity/aesophia_cli#67. I guess @dincho would be quite happy to see that integrated :-)

[marc0olo]

Currently, it is only a part of contract descriptor, it is not meant to be edited by user. Descriptor is created on contract deployment.

but the ACI included there differs from the original response of the http compiler. that's what confused me and I guess also @loxs when he had to deal with this recently

[loxs]

  const compiler = new aesdk.Compiler(COMPILER_URL);
  const compiledContract = await compiler.compileContract({
    code: source,
    options: {},
  });
  const sdkACI = await compiler.generateACI({ code: source, options: {} });
  const encoder = new aecalldata.Encoder([
    ...(sdkACI.externalEncodedAci || []),
    sdkACI.encodedAci,
  ]);

@marc0olo - this is how I deal with it at the moment

[marc0olo]

yeah, I am just saying that ACI usage in general seems very inconvenient right now with SDK and CLI. we need to provide usage guides for that and ideally also prevent missunderstandings around it @davidyuk

especially as we cannot "just use" the (native) response of the http compiler fetched e.g. via curl

[davidyuk]

we somehow need to provide a way to compile with includes

it is implemented in #206 👌

especially as we cannot "just use" the (native) response of the http compiler fetched

This is a tricky thing, I would keep using camelCased JSON's in JS world. Is it ok just to add a command to generate aci using cli? (#207) Alternativelly, I can make cli to support both "raw" and sdk-processed ACI.

[marc0olo]

This is a tricky thing, I would keep using camelCased JSON's in JS world. Is it ok just to add a command to generate aci using cli? (#207) Alternativelly, I can make cli to support both "raw" and sdk-processed ACI.

not sure about the best way to solve it. for the SDK usage alone I agree. as CLI user I might get the ACI from compiler and wonder what's going on and how to use it.

we definitely need better instructions and provide clarity to users in this field. I think for contract interactions independent of deployment the ACI should be the preferred and advertised way to use. do you agree?

[marc0olo]

@davidyuk let's continue in #207