This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-25
Channels
- # aws (1)
- # bangalore-clj (9)
- # boot (97)
- # capetown (1)
- # cider (4)
- # clara (1)
- # cljs-dev (2)
- # cljsrn (109)
- # clojure (258)
- # clojure-finland (3)
- # clojure-greece (2)
- # clojure-italy (1)
- # clojure-russia (33)
- # clojure-spec (41)
- # clojure-uk (46)
- # clojurescript (57)
- # component (17)
- # core-async (6)
- # datomic (13)
- # devcards (10)
- # dirac (2)
- # euroclojure (1)
- # figwheel (1)
- # funcool (1)
- # hoplon (472)
- # luminus (17)
- # off-topic (1)
- # om (16)
- # onyx (40)
- # pedestal (14)
- # proton (12)
- # re-frame (27)
- # reagent (15)
- # ring-swagger (2)
- # specter (5)
- # testing (4)
- # untangled (258)
- # vim (4)
if you merge boot-hoplon
into hoplon
, you can't have a hoplon
only runtime dependency, because now you depend on boot
too.
im not sure if it's a good idea to merge the two.
is there an gh issue somewhere discussing this or just the conversation here on slack?
i see what you mean now. a library that depends on the hoplon runtime parts necessarily brings in the task
afaik all discussion has been on slack
maybe a Merge with Hoplon on the boot-hoplon
GH issues?
so we can enlist and compare the pros and cons?
that sounds good
i've come back around to keeping them separate. it still could be messy but that seems to give people the most flexibility
it occured to me we could have an "easy" option, a 3rd artifact that just depends on boot-hoplon and hoplon
e.g. boot-pack or smth
then we have the ease of a single artifact, but retain the flexibility to specify different task/runtime versions
we just have to be a bit more considerate when releasing hoplon
and see how does it play with boot-hoplon
but actually how are you even testing wether a hoplon
release is okay without running boot-hoplon
...?
yeah, hoplon depends on boot-hoplon via compile
the sensitivity there is bidirectional i think
e.g. boot-hoplon might be sensitive to the hoplon dep
i think things are easier to debug if libraries depend on just the hoplon runtime, not necessarily also the boot task
but yeah. further discussion would be good 😄
I'm seeing more and more value in https://rfc.zeromq.org/spec:42/C4/ like why do they say: > 2.4. Development Process > 1. Change on the project SHALL be governed by the pattern of accurately identifying problems and applying minimal, accurate solutions to these problems. > ... > 5. Users SHALL NOT log feature requests, ideas, suggestions, or any solutions to problems that are not explicitly documented and provable.
@alandipert I think it might be better to keep them split IMHO If Hoplon depends on a specific version of boot-hoplon (test scope) I dont see there being a problem, boot-hoplon can also depend on a specific version of hoplon (compile scope) since these would each be now a minimum version of hoplon this should all just work nicely unless you update hoplon and not the task, which is a minor issue i think
for example boot-hoplon can now depend on hoplon7 (or whatever we call it) and hoplon can depend on boot-hoplon1 the projects can safely move forward from there no?
@flyboarder i was not following the conversation very closely, but it would be good to consolidate this on the issue i just created
ill post a response there
the crux i think is libraries that depend on hoplon, bring in the boot task
it would seem that having separate deps gives future us more leverage navigating maven things
what about this: a library of components depends on hoplon.core. i use this lib from my app. then there's innovation in hoplon and i want to use a newer boot-hoplon, but i can't do both that and use this library
well, im not sure what does merging mean in that case, but that's why i made the issue, so we can discuss it there
to clarify, merging boot-hoplon into hoplon does not make hoplon depend on boot in any way
in tihs case if they remained separate deps, i could independently update my boot-hoplon dep and still use the library
i just saw the second time this topic of "merge boot-hoplon and hoplon" came up but the conversation fragments i read didn't make it clear for me what is the motivation behind this. in other words what problem is it going to solve specifically.
a compatibility matrix seems better than no compatibility story
it feels like a confus to merge two dependencies that have implications at separate 'phases'
since you suffer the other no matter what, end user has no leverage
the example above, how to solve?
a library of components depends on hoplon.core. i use this lib from my app. then there's innovation in hoplon and i want to use a newer boot-hoplon, but i can't do both that and use this library
just spitballing here
so suppose i have an app that depends on hoplon/ui, which depends on hoplon 7.0 or whatever
hoplon/ui has nothing to do with the boot-hoplon task
it doesn't call it or use it any way, just drags it in
no it's not the same
because usually those libraries depend on the logging frameworks as dependencies
it would be like if hoplon/ui depended on each of hoplon and boot-hoplon
then i could exclude boot-hoplon easily, the way i can exclude logging deps
so if you are using boot-hoplon in your project, you will have a direct hoplon dependency
the thing we want to specifically prevent is someone using a newer version of boot-hoplon with an older version of hoplon
i see, so the answer is, bug hoplon/ui to upgrade i foyu want to upgrade
but what if it's not compatible with hoplon/ui
i guess it will always be backward compatible?
we definitely don't want to have to worry about compatibility across major versions between boot-hoplon and hoplon
okay, i just checked the issues, not the pull requests before i created https://github.com/hoplon/boot-hoplon/issues/10 ... sorry
moving to having a boot.jar for each release of boot, even when boot.jar might be the same for multiple versions, made that compatibility matrix unnecessary
it seems like a different scenario, in boot the dependencies share an environment
like, everything in the boot runtime depends on what happened previously
vs. boot-hoplon, the mission of which is to compile into cljs
that's why it makes sense to release a new version of boot-hoplon for each version of hoplon
i for example almost don't use boot-hoplon
because dont want any magic preprocessing happen, since cursive wont understand it and wouldn't let me "jump to definition", "see usages", autocomplete, give help, resolve symbols in general...
there is nothing forcing you to require that namespace and put the hoplon task in your build pipeline
i still use the fact that it generates an index.html and includes an index.html.js into it, but just for that im not sure i want to have any boot task magic
there are tons of files you don't even know about in the jars you add to your classpath
actually.... i do see them in intellij and that's why im a bit against lumping together code which serve very different purposes
it would be a shame to organize dependencies based on the ui limitations of a specific IDE
i just said that im very much aware of the amount of shit library developers put into the jars they deploy...
the specific problem that PR addresses is incom[patibility between hoplon and the boot tasks
currently we need to post a matrix of which version of boot-hoplon to use with a specific version of hoplon
did someone have this problem?
that definitely doesn't seem like our job
my concern tho is that by combining the deps we make it impossible for other people to do
incompatibility isn't a single shoe
for some people it will work, for others it won't
by keeping the deps separate they can decide what to do based on their circumstances
like maybe the part of hoplon/ui i'm using that needs the old hoplon works just fine
like maybe it depends on the behavior of some multimethod in an old hoplon
i propose this strawman
keep the deps separate, but make hoplon a dep of boot-hoplon
so if you just depend on boot-hoplon, you get a known-working setup
now if you start to depend on libraries that use old hoplons, you enter hell and that's on you
at least you can exclude bits
this is exactly how the logging things work (or don't)
i dunno though, maybe it's better to couple them and force people to update
the DI works because they have initialize staticly and the names of the incompatible logging classes are the same
so if you depend on e.g. datomic which brings in logger foo 1.2.3 and aws brings in foo 1.3.1
your import of the class might do something different
since the logging things are named transitive deps you can exclude the one that doesn't work
maybe the logging thing is a bad example though, because those are libraries, and we want to be a framework
just as a side note, i've added the [cloth "0.3.1"]
dependency ( https://clojars.org/repo/cloth/cloth/0.3.1/cloth-0.3.1.jar) to my hoplon project and nothing has appeared because that file contained an index.html
...
so i was worried that i would end up in a similar situation when i include a hoplon dep which contains a boot-hoplon task which then depends on a specific version of boot and all that is downloaded, even when i don't use the boot-hoplon task
and probably most peoples lives are simplified if we bundle up as much known-working stuff as possible, even if it makes certain esoteric things impossible
yeah, definitely don't need to worry about boot-hoplon messing with your boot version
every few week im setting up a new account / machine and im still encountering boot 2.5.5 being downloaded (from the hyper slow http://raw.github.com) when i actually want 2.6.0 or even 2.7.0 finally
and it keep downloading a bunch of small pom files for earlier versions of the boot.core,pod,worker etc libs veeery slowly....
i know it's not directly relevant to the current question, im just explaining why do i care about avoiding unnecessary code coupling
im a bit tired already, so i cant think very clearly, but let me put it out there:
there is boot-cljs
and it's latest version is 1.7.x-abc
it was following the clojurescript version but then it didn't need further updates for awhile so it works with clojurescript 1.9.x
too
so keeping version numbers in lockstep and releasing packages solely with a version number bump might lead to such convergence
in the Java world Hoplon and boot-hoplon would be modules in the same project - released with the same version every time one or the other changed.
would one depend on the other?
in Hoplon case - there's no need. Usually you'd have something like hoplon-tools
that'd transform in a build-tool agnostic way
compilers i've seen on the jvm tend to have 2 deps, the compiler and the runtime
both same version, compiler depends on runtime
that's true, not necessarily
i think it's done to indicate which version of the runtime the compiler corresponds to
it just seems overly complicated to have two separate artifacts that the user needs to understand the relationships between
i put in some disgusting hacks to sniff the classpath to see if it's building an older version of hoplon
but i don't want to do that anymore, becuase i don't feel very confident that it can be done well
whenever hoplon.core is updated there could be changes that need to be made to boot-hoplon
how does the user know that hoplon 6.0.0-alpha17 needs boot-hoplon 0.3.0 but hoplon 6.0.0-alpha16 needs boot-hoplon 0.2.5?
I'd vote for moving boot-hoplon and Hoplon into the same Git project and creating a release
task which would release both with the same version (so option 2 from your list). Purely because there are people who won't use boot-hoplon at all and feel strongly against unneeded dependencies.
what is the harm of having a few extra files in a jar that you can completely ignore if you want to?
i would contest that this is in any way an escape from dependency hell
because there will still be libraries that depend on old versions
and will only work with them
if something depends on hoplon version X, and they use boot-hoplon, there is a specific version of boot-hoplon they will need to use
right, that's the way it is now, and i like it
if you depend on an old version of boot-hoplon and a new version oof hoplon then your build will just be broken
it seems like the main user unfriendliness here is the disparity between versions
if we just line them up, it's super easy to see and know
no, because you retain the ability to exclude one or the other in weird scenarios
you lose this with a single artifact
i can't think of any situation where you'd need to exclude boot-hoplon from hoplon if you are using boot-hoplon
boot-hoplon doesn't depend on boot, but it won't work if your entrypoint wasn't boot
which seems to make it build-tool dependent?
the only thing that changes is when you have version X.0.0 of hoplon and version Y.0.0 of boot-hoplon
i agree there
so i guess in the hoplon/ui example
so if you say that the only thing we support is same version for both, there is no reason not to roll it in there
let's say hoplon/ui depends on hoplon X.0.0
there's also no reason to do it
what?
and since there is only one valid version of boot-hoplon once hoplon version is selected, there is no point to the transitive dep
there are good reasons to put different kinds of things in separate artifacts though, otherwise maven and it's methods of screwing you wouldn't exist
i wanna understand the hoplon/ui example
so let's say we have consolidated and in my app i depend on hoplon Y
but i use a hoplon/ui that depends on X
suppose the hoplon runtime component in X and Y is compatible, incidentally
but the boot tasks are not
like X runtime works with Y, but Y task doesnt' work with X
or whatever the scenario would be where i can't make it work
there is a problematic scenario here though isn't there?
once you choose a version of hoplon you have implicitly chosen a version of boot-hoplon
so i could eitehr choose to use the version that works with ui
or use Y and send a PR to ui for Y
well the question of which version of hoplon.core hoplon/ui is compatible with is a totally separate thing that has no relation to boot-hoplon at all
it's related only because they share an artifact, it seems
it definitely would not be related at all if they were separate
i guess that's because we don't ship .hl in libraries?
i think i am beginning to Believe anew
there is no way to tell maven that a specific version of one thing demands a specific version of another thing
i see now why this is different than the usual compiler/runtime scenario with scala or whatever
because libraries don't contain input to boot-hoplon
it's hard to believe there isn't a single realistic scenario where you could benefit from being able to pick and choose
and you think this will be better for the library system in the long term?
Actually we do ship hl files as it stands
ok i see now
so in summary, it's ok to merge them because there isn't any reason you'd want ot use an older version of boot-hoplon, because it will always be backward-compatible
With the manifest option you need boot-hoplon anyway, if I write a library I now depend on both deps
@flyboarder any reason in particular you ship .hl instead of converting and then pushing?
That breaks things
i see, that's an unfortunate imposition of cljsc i suppose
it can't just friggen deal with it
I just don't know if we want to deprecate a repo is all
I'm fine with either way
It makes sense to require the same version of boot-hoplon as hoplon itself but that is the same as rolling them together I guess, but what about when Lein-hoplon comes around? Do we merge that too?
Well it seems that the code base would be rather large at that point, I don't really see people upgrading hoplon and not boot-hoplon
lein-hoplon would just need to uphold the backward-compatible contract
tha'ts like, the compiler contract i guess
the clojure whay
(in jack black voice whaay)
like "will this new version of hoplon beak things for people who don't upgrade boot-hoplon?"
absolute not
yeah that's like cross-compiling and hoping it still works
But I wonder if that isn't a good issue to come across, if you are using boot-hoplon make sure you check the versions which boot lets us do, usually I want to be running the latest of everything, this is going to require more frequent releases to fix issues would it not?
Since we are now fixing boot tasks and the hoplon core
Hmmm I see
and no issues like we have now with things in master that can't be released until the other is released
Like I said I'm up for either way, just feel bad for the poor deprecated repo
we could deploy to them both lol
same exact artifact
That might cause problems
they just need to know that maven could screw them sometimes and they will need to intervene
i guess our community is small enough we can just put hte word out
and things will hopefully be much more reasonable for the midterm
and the older versions of hoplon cotinue to work with whatever version of boot-hoplon you were using of course
it's worth noting that the merge works well because boot-hoplon doesn't drag a whole bunch of other dependencies
Well I thinks it's a convenient solution for people to have 1 dep and get all the hoplon awesomeness
and then we need to tell the user that when they type [hoplon 1.2.3] they also need to type [boot-hoplon 1.2.3]
That could also work since after the first sync they should be compatible
I guess having different major versions only adds to the confusion
The more I think about ways to keep boot-hoplon compatible with hoplon, the more merging is just easier all around
Here is another thought, what about removing backwards compatibility from boot-hoplon then? Seems silly to focus on it when we are making users upgrade anyway. What I mean is remove the auto include of hoplon.jquery
If we remove that part the need to merge the projects goes away since that is the only breaking change in the boot task, if you are using hoplon7 you will need to specify an attribute provider, which you need to do for the goog provider anyway.
It seems we have a compatibility break either way, you either add a provider or remove the boot-hoplon dependency, or if you want gcl you would need to do both
because then the choice of boot-hoplon is really tightly coupled to the version of hoplon
basically it boils down to this: if there is only one version of boot-hoplon that is compatible with a specific version of hoplon, then having separate artifacts is only a complication
But not if we remove the hoplon.jquery include, then the existing boot-hoplon still works
because the user is forced to maintain the correct versions on their own end, but there is only one correct choice
no, what happens if you use a different version of boot-hoplon with a version of hoplon that doesn't have jquery by default?
Right but you are only missing attributes, so you refer the correct provider
Hmmm, I think it might just be easier to say hey, after version7 include your own provider and not mess around with the boot task, I mean we can still merge it if we wanted to, either way the user is making more changes than just updating hoplon
If a user has to make additional changes anyway, then we need an upgrade guide
But the only real change is the attribute provider not being in core anymore
Seems like we are making a lot of changes to avoid typing hoplon.jquery
but at least that way they know what's going on internally
that is to say if you have a project that's building and working today, you should be able to update hoplon without breaking it
But either way I can't just update hoplon and build, I'd need to make other changes right, is that more or less developer friendly?
Well for one I'd need to remove boot-hoplon that seems like as much work as adding hoplon.jquery except I'm not messing with deps
Ok makes sense, just another question, if we are already warning the user couldn't we also set the correct boot-hoplon version? Or warn if it's too low?
Right, again I'm all for merging, just trying to explore the options
I think for user adoption having 1 dep regardless of useless files being in the jar is the simplest of solutions
For most people they will probably use the boot task anyway
i want it to be safe to update hoplon to a newer minor version without needing to change any application code
Agreed, if we make breaking changes we should make all of them now with the next major
the next major version should only be released when a user who uses no deprecated features of the current version will be able to use the new major vesion without problems
Right, my only concern is the deprecation of an entire repo, but you and @alandipert are the ones you have to maintain that 😜
Agreed, it just might be confusing for newcomers that there is a boot-hoplon repo but that's why I made the deprecated badge
Yeah I guess by version 8 or 9 the repo could be deleted without anyone noticing
Right
If you are all fine with this stuff then we should start to document the deprecated stuff in a road map
the hoplon project has accumulated various cljs hacks that may or may not want to include in hoplon itself
Are the things in a ticket somewhere already? Or just the ns+ one?
Sounds good, I think we should add the http://Waffel.io integration if we are going to start using a real task mgmt system
Waffel bot added
is there a hoplon/ui canvas example?
ok. I saw that line where the canvas primitive was created. Would a similar line do svg?
where with-let
is a hoplon util that returns the element in the let binding after the mutations
right, I remember reading about that the other day. Wasn't exactly sure where/when to use it tho. thx!
ok, nice!
Yeah, I just dupped the canvas line and replaced canvas with svg but since I couldnt' figure out how to do canvas,.. well, that's why I asked.
I've been playing around with the video primative. Your demo videos weren't online for me so I replaced them with a local one.
worked good but I couldn't get them to loop nor have the control bar be functional (but it showed up).
so UI is filtering certain attributes from the underlying JS functionality (like in video, :width, :height, or "img," :src, if UI is best to handle them, like with :s and :url)? Does everything else just get passed through directly?