Add support for accessing `Cargo.toml` values

[daniel-abramov]

Currently some of the values like crate version or crate name are already present in the generated file, however not all of values are present.

What I would like to suggest is to create some sort of the config, which contains every field from Cargo.toml, i.e. to use toml and serde-derive to parse the Cargo.toml and store in an appropriate structure.

When the user needs some values from Cargo.toml, such approach would allow the users to inspect the content of Cargo.toml which was used for the crate when it was built.

I encountered this issue today: there are several values defined inside Cargo.toml in [package.metadata.bundle] section, and I would like to be able to access the values from the code.

[lukaslueg]

We currently do not use cargo's own API to parse Cargo.toml or Cargo.lock, although this would be the right thing to do: The complexity involved in workspaces, out-of-path-builds, cargo's configuration and so on could only be represented by actually using cargo's API. This would, however, add a lot of complexity to built itself. So I'm hesitant to offer any API to actually parse Cargo.toml, if included by built. Is you use-case simple enough to parse Cargo.toml yourself?

[daniel-abramov]

The complexity involved in workspaces, out-of-path-builds, cargo's configuration and so on could only be represented by actually using cargo's API. This would, however, add a lot of complexity to built itself.

Wouldn't it be sufficient to use CARGO_MANIFEST_DIR to get the directory where the manifest is stored and then use it to read Cargo.toml?

Is you use-case simple enough to parse Cargo.toml yourself?

You mean to alter the build script and add an additional step which reads Cargo.toml into a special config structure? - Yes, this is one of the solutions, and most likely I'll go for it as I need this logic in my project, but I just thought that it would be a nice addition to built crate as well :)

This is quite a simple thing to do (basically the config structure has to be defined and then serde_derive would do the job, after the path to Cargo.toml is specified), but I'm just thinking that it's a boilerplate code, which may be a part of a library / crate (built).

[lukaslueg]

Yes, the most basic solution would be to just suck in Cargo.toml from wherever CARGO_MANIFEST_DIR points to and serialize it as a [u8; _]. The correct way to parse that would be cargo itself, and there is a lot to it. I'd like to have built not provide/forward an API for that, so you'd have to de-toml the values you are looking for yourself. It's just a few API calls though.

[Shnatsel]

I made a very basic prototype implementation of this a while ago and opened an RFC for Cargo: https://github.com/rust-lang/rfcs/pull/2801

[jayvdb]

https://github.com/lukaslueg/built/issues/49 may be of some use, allowing access to only direct dependencies, which is closer to the dependency list that appears in Cargo.toml.

With cargo workspaces, it would now be necessary to store either:

1. both member and workspace Cargo.toml in order to be useful, but then understanding them at runtime is hard, or
2. store a flattened composite of the two, but then someone will have a use-case for wanting to know whether a value was inherited or not.

IMO option 2 is the one to shoot for.