Comments (8)
I'd say we start with mimicing toml-rs
, ie able to pass their tests
- https://github.com/alexcrichton/toml-rs/blob/master/test-suite/tests/formatting.rs
- https://github.com/alexcrichton/toml-rs/blob/master/test-suite/tests/pretty.rs
We can look to their serde implementation for a starting point for the algorithm: https://github.com/alexcrichton/toml-rs/blob/master/src/ser.rs
Without looking to closely
- We should always create valid toml
- We should prefer array of tables over inline arrays
- If a table has too many elements, we should prefer standard tables over inline tables.
from toml.
That makes sense. A similar thought i had was a way to control sort order (e.g. [package], [features], [dependencies], [target]).
The main thing is balancing the complexity, whether thats in a user finding what they want and understanding how to use it, implementing the users code on top of the API, or the implementation within the library. At a certain point of proliferation of customization, it seems like it'd be better for someone to walk the data structure and format it manually. I guess another aspect of all of this is finding the answer to what can we do to support people writing that custom formatting.
Oh that's a super interesting idea. I wonder what an API based on syn::visit_mut
would feel like. Going to try playing with it a bit over the next few days.
btw guppy looks interesting! In particular, I find the idea of determinator interesting from two angles
Thank you! Yeah, the determinator is really cool and has proven to work quite well in a large workspace. I think both of the use cases you described make a lot of sense.
I haven't seen much demand for it in open source yet but now that you've asked for it, I now have a reason to clean it up and put it out there :) Happy to chat about this in more detail on Discord or some other medium.
from toml.
I propose that Document
, Table,
, etc have fmt
functions that take a format configuration. to_string_pretty
and other serializer options are implemented in terms of this.
This function will be the public facing one. An internal one will be used when recursing so we can pass in the relevant information from the caller, in addition to the format config.
from toml.
We should port the following tests when we do this
- https://github.com/alexcrichton/toml-rs/blob/master/test-suite/tests/formatting.rs
- https://github.com/alexcrichton/toml-rs/blob/master/test-suite/tests/pretty.rs
from toml.
Hello, I've just touched this. Let me state my understanding of the question and see if my understanding is correct.
It seems that you don't think the printout of the current structure, such as Table
and document
, is perfect. Therefore, the function easy::to_string_pretty
needs to be optimized, right?
If my understanding is correct, what is the perfect output format you want?
Please give me a detailed description. Thank you.
from toml.
Example failure from cargo's test suite
---- features_namespaced::publish stdout ----
running `/home/epage/src/personal/cargo/target/debug/cargo publish --token sekrit -Z namespaced-features`
thread 'features_namespaced::publish' panicked at '
error: did not match:
1 1 # THIS FILE IS AUTOMATICALLY GENERATED BY CARGO
2 2 #
3 3 # When uploading crates to the registry Cargo will automatically
4 4 # "normalize" Cargo.toml files for maximal compatibility
5 5 # with all versions of Cargo and also rewrite `path` dependencies
6 6 # to registry (e.g., crates.io) dependencies.
7 7 #
8 8 # If you are reading this file be aware that the original Cargo.toml
9 9 # will likely look very different (and much more reasonable).
10 10 # See Cargo.toml.orig for the original contents.
11 11
12 -[package]
13 -name = "foo"
14 -version = "0.1.0"
15 -description = "foo"
16 -homepage = "https://example.com/"
17 -license = "MIT"
18 -[dependencies.bar]
19 -version = "1.0"
20 -optional = true
21 -
22 -[features]
23 -feat1 = []
24 -feat2 = ["dep:bar"]
25 -feat3 = ["feat2"]
12 +package = { name = "foo", version = "0.1.0", description = "foo", homepage = "https://example.com/", license = "MIT"}
13 +dependencies = { bar = { version = "1.0", optional = true}}
14 +features = { feat1 = [], feat2 = ["dep:bar"], feat3 = ["feat2"]}
from toml.
Thanks! I ran across this while trying to see if I can switch my code to using toml_edit
(which looks fantastic btw!)
I'm wondering if at some point, finer-grained control might be desirable -- perhaps some sort of trait that can control whether a particular table is serialized as inline or standard. e.g. for a Cargo.toml
, I'd like to see dependencies.bar
be an inline table but features
be a standard table.
from toml.
I'm wondering if at some point, finer-grained control might be desirable -- perhaps some sort of trait that can control whether a particular table is serialized as inline or standard. e.g. for a Cargo.toml, I'd like to see dependencies.bar be an inline table but features be a standard table.
That makes sense. A similar thought i had was a way to control sort order (e.g. [package]
, [features]
, [dependencies]
, [target]
).
The main thing is balancing the complexity, whether thats in a user finding what they want and understanding how to use it, implementing the users code on top of the API, or the implementation within the library. At a certain point of proliferation of customization, it seems like it'd be better for someone to walk the data structure and format it manually. I guess another aspect of all of this is finding the answer to what can we do to support people writing that custom formatting.
btw guppy looks interesting! In particular, I find the idea of determinator interesting from two angles
- For build/test avoidance in open source. For example, clap's CI takes over an hour (they did switch to a two-tier CI using bors so that cost is only paid on merge and not each PR update, instead its only a half hour or so which is still bad). I would love to also have coverage-driven test case avoidance but thats its own separate thing.
- As a maintainer of one of the release automation tools (cargo-release). We've all been implementing our own bespoke implementations of release-avoidance. These have their own needs. For a release, all you care about is included/excluded files. You also only need to release all packages with a
[[bin]]
if the lock file changed. I wish there was a way to know if a dependency showed up in a public API.
from toml.
Related Issues (20)
- Examples need improvement - missing basic example that reads from a file, not a string variable. HOT 1
- toml_edit: Confusing deprecation message - decor_mut states it's deprecated in favour of itself
- Deprecated field warning during deserialization HOT 4
- Inconsistencies between documentation and code implementation HOT 2
- Replacing an `InlineTable` with a comment with a `Table` results in invalid syntax HOT 2
- inclusion of another toml file and variable substitution HOT 2
- Time doesn't implement Serialize and Deserialize HOT 5
- Remove `Item` support from `Document`s API HOT 2
- Stack Overflow with Specific Optimization Levels When Running Test Cases HOT 6
- Fix u64 deserialization HOT 6
- Multi-line k/v pairs HOT 1
- Serialization of keys varies depending on whether the feature flag "parse" is enabled
- Array of Tables `remove` does not return the removed table
- Implement `From<inner type>` for `Item`
- Decor in `DocumentMut` is ignored HOT 2
- Feature proposal: Type-safe decor mutation API HOT 1
- Allow to create `Decor` instances with optional prefix or suffix
- How to serialize/deserialize while preserving formats with `toml_edit`? HOT 3
- [Bug] `de::from_str` has overly strict generic restrictions. HOT 1
- How to use `Spanned` HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from toml.