That is a nice package @Ronis_BR! Thanks!
Would it make sense to have it as a dependency in DataFrames.jl and use it there? The current print methods in DataFrames.jl aren’t that flexible.
cc: @bkamins
That crossed my mind, too. But, I think it’s more ambitious than PrettyTables is at the moment. The right way to go about it would be to define a generic interface for printing table-like things with PrettyTables. In fact it would probably be fairly easy to make minor changes to DataFrames to allow it to work with a PrettyDataFrames glue package, so people can try it out and see if it is strongly preferred.
I think the right approach is not to have PrettyTables.jl as a dependency in DataFrames.jl, but change DataFrames.jl in such a way that PrettyTables.jl can overwrite the default printing.
If I understand you correctly this is exactly what you propose - right @jlapeyre?
If yes - what would be the changes needed in DataFrames.jl to follow this path?
Or maybe in general it should be Tables.jl not DataFrames.jl to be even more flexible.
Yes, that’s exactly what I was thinking about. I guess a glue package between PrettyTables and Tables would be the most useful. I don’t know enough to details to say more. It makes sense to offload the display code for tables, like eg. using CSV for saving/reading.
This might be drifting from what PrettyTables was meant to be.
But, if it were to work, I guess such an interface would be very widely appreciated.
Maybe the best approach is provide a way to “register” in Tables.jl a printing system. Then the users can select whatever they want by loading the specific package that will register itself using this API. PrettyTables.jl was thought to be a printing system for Text tables, we have others for LaTeX, etc.
One can print quite nice tables with just 30-odd lines of Julia code, as in
OK guys, I bring updates!
Now we have a documentation (even an icon! 
), which can be accessed here.
I also did some modifications, as the introduction of what I called sub-headers. Basically, you can now have multiple lines in the header to add information such as the unit of the data:
Using this, PrettyTables.jl can now print DataFrames.jl showing the types (as the default print system of DataFrames.jl does).
Now my next steps should be:
- Wait for the package be approved on METADATA.jl
- Figure out what to do when the data is too wide to fit the screen (ideas?)
How do I add your package PrettyTables.jl
julia>
$ julia
_
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.0.3 (2018-12-18)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |
julia>]
(v1.0) pkg> add PrettyTables
Updating registry at `~/.julia/registries/General`
Updating git-repo `https://github.com/JuliaRegistries/General.git`
ERROR: The following package names could not be resolved:
* PrettyTables (not found in project, manifest or registry)
Please specify by known `name=uuid`.
Please help.
try
] add https://github.com/ronisbr/PrettyTables.jl
I think it worked. I will find out soon
julia>
$ julia
_
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.0.3 (2018-12-18)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |
julia>]
(v1.0) pkg> add https://github.com/ronisbr/PrettyTables.jl
Updating registry at `~/.julia/registries/General`
Updating git-repo `https://github.com/JuliaRegistries/General.git`
Cloning git-repo `https://github.com/ronisbr/PrettyTables.jl`
Updating git-repo `https://github.com/ronisbr/PrettyTables.jl`
Resolving package versions...
Installed DataStructures ─── v0.15.0
Installed NearestNeighbors ─ v0.4.3
Updating `~/.julia/environments/v1.0/Project.toml`
[bf2635c2] + PrettyTables v0.1.0 #master (https://github.com/ronisbr/PrettyTables.jl)
Updating `~/.julia/environments/v1.0/Manifest.toml`
[864edb3b] ↑ DataStructures v0.14.0 ⇒ v0.15.0
[b8a86587] ↑ NearestNeighbors v0.4.2 ⇒ v0.4.3
[bf2635c2] + PrettyTables v0.1.0 #master (https://github.com/ronisbr/PrettyTables.jl)
julia> data = ["Col. 1" "Col. 2" "Col. 3" "Col. 4";
1 false 1.0 0x01 ;
2 true 2.0 0x02 ;
3 false 3.0 0x03 ;
4 true 4.0 0x04 ;
5 false 5.0 0x05 ;
6 true 6.0 0x06 ;]
7×4 Array{Any,2}:
"Col. 1" "Col. 2" "Col. 3" "Col. 4"
1 false 1.0 0x01
2 true 2.0 0x02
3 false 3.0 0x03
4 true 4.0 0x04
5 false 5.0 0x05
6 true 6.0 0x06
julia> pretty_table(data)
ERROR: UndefVarError: pretty_table not defined
Stacktrace:
[1] top-level scope at none:0
julia> using PrettyTables
[ Info: Precompiling PrettyTables [bf2635c2-15c2-11e9-0b27-5fb50ccc2906]
julia> pretty_table(data)
┌────────┬────────┬────────┬────────┐
│ Col. 1 │ Col. 2 │ Col. 3 │ Col. 4 │
├────────┼────────┼────────┼────────┤
│ Col. 1 │ Col. 2 │ Col. 3 │ Col. 4 │
│ 1 │ false │ 1.0 │ 1 │
│ 2 │ true │ 2.0 │ 2 │
│ 3 │ false │ 3.0 │ 3 │
│ 4 │ true │ 4.0 │ 4 │
│ 5 │ false │ 5.0 │ 5 │
│ 6 │ true │ 6.0 │ 6 │
└────────┴────────┴────────┴────────┘
It worked. Thank you.
This is excellent. I really like the generality of an API. This is great for visualization of results.
This will work as soon as it gets accepted in METADATA!
Looks nice – I’ll try it soon. Question: someone suggested that it would be great if it is possible to “LaTeXify” the table, i.e., so that we can paste the table into a LaTeX document. Is that something that might be possible?
If you read the thread you will find 2 options for that.
Package was accepted and updated!
Now you can install it by typing ]add PrettyTables.
I would love some feedback! I am expecting lots of bugs…
Very useful !
Does it make sense to add limiter (like in print_matrix) ?
Thanks! I do not know. Maybe it will be nice to add a limit when the screen is not big enough to fit the data. But then I think this is a package to print data and not create data, then is it useful to omit data?
It is a good discussion… what do you think?
I found the output so nice that I was considering to use it as the default output for my own ND-Array struct…
In this case the limit makes sense (I use print_matrix right now). I understand that this use case is a bit out of the primary scope of your package 
Ah, Good! I see. Well, then yes 
I will see if I can do such limit.
Thanks – I assume you refer to the suggestions (1) LatexPrint, (2) Latexify, and (3) TexTables. What I meant by my questions was more whether it is possible to pipe the result of PrettyTables into, say, Latexify – which might be interesting if PrettyTables has more (or rather: simpler) control of the layout/typesetting. Anyway, I’ll check around a little.