# Current state and the future of PrettyTables.jl
**URL:** https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455
**Category:** Package Announcements
**Tags:** prettytables
**Created:** [August 21, 2024, 2:18pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455 "2024-08-21T14:18:22Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@Ronis\_BR](https://discourse.julialang.org/u/Ronis_BR)
#### Post date: [August 23, 2024, 7:50pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/21 "2024-08-23T19:50:23Z")
> [@jar1](#):
>
> Is there support for nested groupings in the rows just like in the columns? Like this
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`:
---
### Author:  [@Ronis\_BR](https://discourse.julialang.org/u/Ronis_BR)
#### Post date: [August 24, 2024, 2:46pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/22 "2024-08-24T14:46:13Z")
I think the summary columns will be interesting for large tables:
---
### Author:  [@alusiani](https://discourse.julialang.org/u/alusiani)
#### Post date: [August 25, 2024, 9:59pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/23 "2024-08-25T21:59:24Z")
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](https://github.com/vincentarelbundock/tinytable). It seems quite well designed and powerful.
---
### Author:  [@fabgrei](https://discourse.julialang.org/u/fabgrei)
#### Post date: [August 26, 2024, 8:14am UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/24 "2024-08-26T08:14:03Z")
I think “row group labels” would be really useful. Do you plan on implementing them?
---
### Author:  [@Strider](https://discourse.julialang.org/u/Strider)
#### Post date: [August 26, 2024, 9:40am UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/25 "2024-08-26T09:40:43Z")
Concur on not creating a new package. It seems that would add to the recurring threads asking “is \_\_\_.jl supported anymore?”
---
### Author:  [@Ronis\_BR](https://discourse.julialang.org/u/Ronis_BR)
#### Post date: [August 26, 2024, 12:06pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/26 "2024-08-26T12:06:54Z")
> [@alusiani](#):
>
> 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](https://github.com/vincentarelbundock/tinytable). It seems quite well designed and powerful.
Thanks! I will study this package 🙂
> [@fabgrei](#):
>
> I think “row group labels” would be really useful. Do you plan on implementing them?
Yes! Next feature to be implemented.
---
### Author:  [@Ronis\_BR](https://discourse.julialang.org/u/Ronis_BR)
#### Post date: [August 27, 2024, 8:40pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/27 "2024-08-27T20:40:43Z")
@fabgrei
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:
```julia
row_group_labels = [
1 => "First Set",
4 => "Second Set",
7 => "Third Set"
]
```
---
### Author:  [@TheCedarPrince](https://discourse.julialang.org/u/TheCedarPrince)
#### Post date: [August 27, 2024, 10:26pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/28 "2024-08-27T22:26:56Z")
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!
---
### Author:  [@Ronis\_BR](https://discourse.julialang.org/u/Ronis_BR)
#### Post date: [August 27, 2024, 10:32pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/29 "2024-08-27T22:32:37Z")
That’s a really nice feedback! Thank you very much 🙂 I am glad it is being useful.
---
### Author:  [@merlin](https://discourse.julialang.org/u/merlin)
#### Post date: [August 29, 2024, 4:10pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/30 "2024-08-29T16:10:35Z")
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.
---
### Author:  [@merlin](https://discourse.julialang.org/u/merlin)
#### Post date: [August 29, 2024, 4:16pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/31 "2024-08-29T16:16:07Z")
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.
---
### Author:  [@merlin](https://discourse.julialang.org/u/merlin)
#### Post date: [August 29, 2024, 4:21pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/32 "2024-08-29T16:21:13Z")
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).
---
### Author:  [@nhz2](https://discourse.julialang.org/u/nhz2)
#### Post date: [August 30, 2024, 11:19pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/33 "2024-08-30T23:19:11Z")
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
---
### Author:  [@technocrat](https://discourse.julialang.org/u/technocrat)
#### Post date: [August 31, 2024, 2:20am UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/34 "2024-08-31T02:20:32Z")
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.`
---
### Author:  [@Ronis\_BR](https://discourse.julialang.org/u/Ronis_BR)
#### Post date: [August 31, 2024, 1:22pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/35 "2024-08-31T13:22:52Z")
> [@nhz2](#):
>
> A given Julia environment can only have one version of a package at a time. So if for example, [CUDA.jl](https://juliahub.com/ui/Packages/General/CUDA) needs [PrettyTables.jl](https://juliahub.com/ui/Packages/General/PrettyTables) v2 and [DataFrames.jl](https://juliahub.com/ui/Packages/General/DataFrames) needs [PrettyTables.jl](https://juliahub.com/ui/Packages/General/PrettyTables) v3, it will not be possible to install the latest versions of [CUDA.jl](https://juliahub.com/ui/Packages/General/CUDA) and [DataFrames.jl](https://juliahub.com/ui/Packages/General/DataFrames) in the same environment. Usually, the way to fix this is to go through all 148 direct dependents of [PrettyTables.jl](https://juliahub.com/ui/Packages/General/PrettyTables) and update them to work with both [PrettyTables.jl](https://juliahub.com/ui/Packages/General/PrettyTables) 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](https://juliahub.com/ui/Packages/General/PrettyTables2)
Yes, I understand this. However, there is some points worth considering:
1. 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.
2. 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.
3. What about the next major release? It would not be nice to have PrettyTables3.jl, PrettyTables4.jl, etc.
4. I found extremely confusing for new users to see something like PrettyTables3.jl v1.2.
5. 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.
---
### Author:  [@Ronis\_BR](https://discourse.julialang.org/u/Ronis_BR)
#### Post date: [August 31, 2024, 1:25pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/36 "2024-08-31T13:25:32Z")
I fully agree! My idea is to implement the following back ends:
1. Text.
2. HTML.
3. LaTeX.
4. Markdown.
5. Typst.
6. Probably org-mode.
From here, we might need to use pandoc to convert to another format.
---
### Author:  [@nhz2](https://discourse.julialang.org/u/nhz2)
#### Post date: [August 31, 2024, 3:16pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/37 "2024-08-31T15:16:02Z")
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.
---
### Author:  [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)
#### Post date: [August 31, 2024, 5:48pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/38 "2024-08-31T17:48:59Z")
> [@Ronis\_BR](#):
>
> [Pkg.jl](https://juliahub.com/ui/Packages/General/Pkg) should really start allowing multiple package versions (private versions) at some point
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.
---
### Author:  [@pdeffebach](https://discourse.julialang.org/u/pdeffebach)
#### Post date: [August 31, 2024, 6:47pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/39 "2024-08-31T18:47:56Z")
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](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/27) 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.
---
### Author:  [@nhz2](https://discourse.julialang.org/u/nhz2)
#### Post date: [August 31, 2024, 7:04pm UTC](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455/40 "2024-08-31T19:04:25Z")
This might be getting off-topic, but there is an RFC for allowing something like this. [RFC: Export versioning · Issue #54905 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/54905)
[Previous page](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455.md?page=1)
[Next page](https://discourse.julialang.org/t/current-state-and-the-future-of-prettytables-jl/118455.md?page=3)