Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display in Juno #902

Merged
merged 2 commits into from
Sep 30, 2016
Merged

Display in Juno #902

merged 2 commits into from
Sep 30, 2016

Conversation

MikeInnes
Copy link
Contributor

@MikeInnes MikeInnes commented Sep 21, 2016

This adds a small, pure-Julia dependency on Juno.jl which enables Gadfly to be display appropriately in the Juno plot pane.

@tlnagy
Copy link
Member

tlnagy commented Sep 21, 2016

I'm all for making Gadfly work nice with Juno, but Gadfly already installs a ridiculous amount of dependencies and I was hoping to reduce the number. Is there any way that we can make this work without enlarging REQUIRE?

Maybe @tkelman knows?

@tbreloff
Copy link
Contributor

Yes. We need support for conditional imports in Base.

(this was for you @ChrisRackauckas!)

@coveralls
Copy link

coveralls commented Sep 21, 2016

Coverage Status

Coverage decreased (-0.2%) to 65.626% when pulling 4728bf7 on MikeInnes:juno into 1bcd9fb on dcjones:master.

@ChrisRackauckas
Copy link

Three things here. 1, I think that "number of dependencies" shouldn't be the deciding factor. It should be whether having the dependency could cause breakage (i.e. the package has precompilation errors and is unstable) or namespace clashes, and additionally if the dependency is a huge install. None of those apply to Juno.jl. The only "problem" is it adds a number to the dependency count (and what, a few KB? May a MB?). I think the culture for evaluating dependencies would be much improved if this was the way it was discussed.

Secondly, Gadfly is another case where conditional dependencies are starting to become a larger issue as the package grows. It seems anything that wants to extend itself with Juno support, support for units, extra plotting support, choices to use methods from different packages as "drop-ins" for native methods, etc. each require more and more dependencies. Gadfly has a lot of dependencies where are only used in a few cases like Loess which should really be conditional dependencies. I think this is a sign that the Julia ecosystem has reached a point where proper use of conditional dependencies is a big issue, and it needs to be addressed in Base. If you want to start pushing the discussion in Base, here are some places to do so:

JuliaLang/julia#6195
JuliaLang/julia#15705

I think the issue is that no one really knows how to deal with it, so any progress towards a PR would be huge plus.

Lastly, note that Juno doesn't actually explicitly need to be a dependency, since Juno will always import Juno.jl on startup. So if you had junoenabled = isdefined(Main,:Juno), then you could conditionally do anything with Juno behind an if statement, and call the Juno functions through Main.Juno. .... That's quite a hack though.

@@ -1105,6 +1105,22 @@ function display(d::REPLDisplay, ::MIME"application/pdf", p::Plot)
open_file(filename)
end

# Display in Juno

import Juno: Juno, @render, media, Media, Hiccup
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are Media and Hiccup going to be dependencies of every version of Juno that will ever be released? if not, better to depend on then explicitly instead of importing them indirectly like this

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The indirect dependency on Media adds a dependency on Requires which is one of the known-to-be-unreliable conditional dependency workarounds.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the idea is that the Media and Hiccup submodules form part of Juno.jl's public API. If that changes it can be handled in the standard way.

The whole point of this PR is to enable Requires.jl to be removed from Media.jl, and from the rest of Atom.jl's dependency tree.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah that would be great

Copy link

@ChrisRackauckas ChrisRackauckas Sep 21, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI @pfitzseb, something like in the Juno stack may have been the cause of the v0.5 upgrade precompilation error seen last night. Not this specifically, but if you used the same conditional dependency workaround somewhere else, it would lead to t and be fixed by the fix in the fix found in the issue:

JunoLab/uber-juno#15

@coveralls
Copy link

coveralls commented Sep 21, 2016

Coverage Status

Coverage decreased (-0.1%) to 65.695% when pulling 8f20462 on MikeInnes:juno into 1bcd9fb on dcjones:master.

@tlnagy
Copy link
Member

tlnagy commented Sep 22, 2016

@MikeInnes It looks like this PR is leading to precompilation errors on 0.4. Any thoughts on why that might be happening?

I think working with Juno is important enough that I'm going to merge this once we figure out what's causing the precompilation problem.

1, I think that "number of dependencies" shouldn't be the deciding factor. It should be whether having the dependency could cause breakage (i.e. the package has precompilation errors and is unstable) or namespace clashes, and additionally if the dependency is a huge install. None of those apply to Juno.jl. The only "problem" is it adds a number to the dependency count (and what, a few KB? May a MB?).

@ChrisRackauckas I agree, but sheer number also matters because the fact of the matter is that upstream Julia packages break regularly*. The more potential sources of breakage the more likely Gadfly is to be broken due to a dependency that is only necessary for 1% of the function of the package.

* and this is unlikely to change till we hit 1.0

@tkelman
Copy link
Contributor

tkelman commented Sep 22, 2016

The Juno 0.1.0 tag that claimed to support Julia 0.4 actually didn't.

@MikeInnes
Copy link
Contributor Author

I tagged a new Juno.jl (JuliaLang/METADATA.jl#6474) which supports 0.4. After that's through the tests should pass again.

@tkelman
Copy link
Contributor

tkelman commented Sep 23, 2016

which supports 0.4

Not according to the require file. Please pay closer attention to dependency requirements and testing on your packages.

@coveralls
Copy link

coveralls commented Sep 27, 2016

Coverage Status

Coverage remained the same at 65.841% when pulling 507edf1 on MikeInnes:juno into 1bcd9fb on dcjones:master.

@MikeInnes
Copy link
Contributor Author

Tests are passing, and I've just removed Requires from Media.jl master – so that's one less dependency.

@tlnagy
Copy link
Member

tlnagy commented Sep 30, 2016

Awesome! Thanks. Lets make Gadfly play nice with Juno.

@tlnagy tlnagy merged commit 44422c2 into GiovineItalia:master Sep 30, 2016
media(Plot, Media.Plot)

@render Juno.PlotPane p::Plot begin
x, y = Juno.plotsize()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like much of the rest of gadfly uses 4 space indent

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants