Unfortunately, I will not support row merging for now. It should be fairly simple in HTML and LaTeX, but it can be extremely difficult in text back end. You can “mimic” the behavior by just passing empty values for the row_labels:
2 Likes
Let me mention that there is a new table-formatting R packages that could also be interesting to consider for the next version of your package: tinytable. It seems quite well designed and powerful.
2 Likes
I think “row group labels” would be really useful. Do you plan on implementing them?
Concur on not creating a new package. It seems that would add to the recurring threads asking “is ___.jl supported anymore?”
3 Likes
Thanks! I will study this package 
Yes! Next feature to be implemented.
1 Like
And now we have row group labels:
The API is a Vector{Pair{String, String}} with the line where the group begin together with the label, for example:
row_group_labels = [
1 => "First Set",
4 => "Second Set",
7 => "Third Set"
]
14 Likes
I am so excited for these updates! I am actually using PrettyTables.jl right now for a paper I am writing. This package is one of my favorites and always makes me excited to see updates coming to it!
5 Likes
That’s a really nice feedback! Thank you very much I am glad it is being useful.
3 Likes
I have been using it at work to generate .html files, ultimately producing images from these or copy/pasting into a google doc. So my use case is basically not knowing how to use PrettyTables. I vote for more examples in the v3 docs.
1 Like
Totally agree. My data flows are shaping dataframes, I want to send these (1 or more completed DataFrame) to PrettyTables for formatting and layout. So I’m expecting data to come in along with configuration to generate the markedup table code I guess.
1 Like
I support only a few Julia packages (at work) so I dont have a lot of experience here, but I thought this was best handled with by pinning the Pkg dependencies? I guess I dont understand the part about different packages taking dependency on different versions, which I thought was a normal part of compatibility (thinking of python package development here).
A given Julia environment can only have one version of a package at a time. So if for example, CUDA.jl needs PrettyTables.jl v2 and DataFrames.jl needs PrettyTables.jl v3, it will not be possible to install the latest versions of CUDA.jl and DataFrames.jl in the same environment. Usually, the way to fix this is to go through all 148 direct dependents of PrettyTables.jl and update them to work with both PrettyTables.jl v2 and v3. If the changes are too drastic to be able to do that (I’m not saying that in this specific case they are), then it probably makes sense to instead change the name of the package to something like PrettyTables2.jl
4 Likes
There are a ton of backends that are in the “nice to have” or “just in case” category. Examples include the word processing formats, RTF, textile, etc. Rather than adding these to PrettyTable, however, it would be preferable to confine the backend work to the cases most often used. I don’t think any additional are needed, but others may have suggestions.
The pandoc program can convert to most of the formats ever likely to be needed. It has a CLI, so it can be called with Cmd type. There’s also an API, but it’s only to Haskell.
It’s also possible to write filters to traverse the JSON abstract syntax tree to modify between parsing and output. Lua filters can do this without an intermediate JSON file.
If backends are to be added to PrettyTables the GitHub code provides a wealth of examples to look to if to be implemented in Julia.
Yes, I understand this. However, there is some points worth considering:
- Packages use PrettyTables.jl just calling one function at the end of processing to show the results. Hence, it should be easy to adapt this one function to the new API.
- Unfortunately, I do not have time to maintain two packages with this complexity. We do have breaking changes in output between minor julia versions leading to problems, which sometimes include to re-generate many test outputs.
- What about the next major release? It would not be nice to have PrettyTables3.jl, PrettyTables4.jl, etc.
- I found extremely confusing for new users to see something like PrettyTables3.jl v1.2.
- Semantic versioning was designed for this kind of change.
I am afraid that if this change leads to major disruption (which I really do not expect), Pkg.jl should really start allowing multiple package versions (private versions) at some point.
12 Likes
I fully agree! My idea is to implement the following back ends:
- Text.
- HTML.
- LaTeX.
- Markdown.
- Typst.
- Probably org-mode.
From here, we might need to use pandoc to convert to another format.
3 Likes
From the changes you are describing, I don’t think you even need to increase the major version number. For example, you could make the header keyword argument just an alias for column_labels so both work and do the same thing. Also, if some of the features are not used or are buggy, then you don’t need to update the major version to remove them.
1 Like
This a 100 times over! I understand that there are concerns for some scenarios (say you use two different packages that both depend on DataFrames, but on different versions, and now you have two distinct DataFrame types floating around in your Julia process). But PrettyTables.jl is probably the example where it would be entirely ok and unproblematic if two different versions were used at the same time: If I’m a user of DataFrames and TypedTables and each used a different version of PrettyTables to show things, all would be fine, no problem at all. And all the concerns voiced above would just go away.
5 Likes
I just have some comments about the use of PrettyTables.jl.
I remain concerned that current development directions are overly expansive. I really just want to print tables in LaTeX and the only feature I would want is multi-column headers.
One thing that I’m curious about is the decision to have summary statistics at the bottom of tables. Like here above.
I rarely use PrettyTables.jl to print “data”, or anything where a sum or a mean would be relevant. I use PrettyTables.jl to print model fit statistics or list parameter values in a model. I don’t want any operation to be done on these columns.
Because PrettyTables.jl is an increasingly widely-used dependency, I think TTFT (Time to First Table) really matters, even accounting for pre-compilation.
2 Likes
This might be getting off-topic, but there is an RFC for allowing something like this. RFC: Export versioning · Issue #54905 · JuliaLang/julia · GitHub
2 Likes