This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 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
hoplon, you can't have a
hoplon only runtime dependency, because now you depend on
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
maybe a Merge with Hoplon on the
boot-hoplon GH issues?
so we can enlist and compare the pros and cons?
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
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
but actually how are you even testing wether a
hoplon release is okay without running
i think things are easier to debug if libraries depend on just the hoplon runtime, not necessarily also the boot task
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
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.
it feels like a confus to merge two dependencies that have implications at separate 'phases'
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
so suppose i have an app that depends on hoplon/ui, which depends on hoplon 7.0 or whatever
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
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
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
my concern tho is that by combining the deps we make it impossible for other people to do
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
now if you start to depend on libraries that use old hoplons, you enter hell and that's on you
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
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
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:
boot-cljs and it's latest version is
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.
in Hoplon case - there's no need. Usually you'd have something like
hoplon-tools that'd transform in a build-tool agnostic way
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?
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
if you depend on an old version of boot-hoplon and a new version oof hoplon then your build will just be broken
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
the only thing that changes is when you have version X.0.0 of hoplon and version Y.0.0 of boot-hoplon
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
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
once you choose a version of hoplon you have implicitly chosen a version of boot-hoplon
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
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
it's hard to believe there isn't a single realistic scenario where you could benefit from being able to pick and choose
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?
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
like "will this new version of hoplon beak things for people who don't upgrade boot-hoplon?"
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?
and no issues like we have now with things in master that can't be released until the other is released
they just need to know that maven could screw them sometimes and they will need to intervene
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]
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?
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
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?
I think for user adoption having 1 dep regardless of useless files being in the jar is the simplest of solutions
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
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
Sounds good, I think we should add the http://Waffel.io integration if we are going to start using a real task mgmt system
ok. I saw that line where the canvas primitive was created. Would a similar line do svg?
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!
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?
hm, actually… i just realized the above example won’t work anymore because the actual html canvas element is now nested as a background div of the