Fork me on GitHub
#hoplon
<
2016-10-25
>
onetom01:10:04

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.

onetom01:10:31

is there an gh issue somewhere discussing this or just the conversation here on slack?

alandipert01:10:40

i see what you mean now. a library that depends on the hoplon runtime parts necessarily brings in the task

alandipert01:10:00

afaik all discussion has been on slack

onetom01:10:48

maybe a Merge with Hoplon on the boot-hoplon GH issues? so we can enlist and compare the pros and cons?

alandipert01:10:57

that sounds good

alandipert01:10:19

i've come back around to keeping them separate. it still could be messy but that seems to give people the most flexibility

alandipert01:10:44

it occured to me we could have an "easy" option, a 3rd artifact that just depends on boot-hoplon and hoplon

alandipert01:10:54

e.g. boot-pack or smth

alandipert01:10:18

then we have the ease of a single artifact, but retain the flexibility to specify different task/runtime versions

onetom01:10:35

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...?

alandipert01:10:11

yeah, hoplon depends on boot-hoplon via compile

alandipert01:10:29

the sensitivity there is bidirectional i think

alandipert01:10:42

e.g. boot-hoplon might be sensitive to the hoplon dep

alandipert01:10:21

i think things are easier to debug if libraries depend on just the hoplon runtime, not necessarily also the boot task

alandipert02:10:27

but yeah. further discussion would be good 😄

onetom02:10:42

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.

flyboarder03:10:17

@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

flyboarder03:10:34

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?

onetom03:10:01

@flyboarder i was not following the conversation very closely, but it would be good to consolidate this on the issue i just created

flyboarder03:10:45

ill post a response there

dm305:10:25

@micha do you think it makes sense to release the hoplon.binding nses as a separate lib?

micha13:10:33

hoplon does not depend on boot though @onetom

micha13:10:52

it just has namespaces in it that do

micha13:10:19

you do not have to use those namespaces if you don't want to

alandipert13:10:49

the crux i think is libraries that depend on hoplon, bring in the boot task

alandipert13:10:20

it would seem that having separate deps gives future us more leverage navigating maven things

onetom13:10:28

But if u would merge boot-hoplon into hoplon then it would, no?

micha13:10:26

no, the pom should not have any boot dependencies

micha13:10:38

the hoplon pom

micha13:10:48

after the merge

alandipert13:10:33

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

onetom13:10:44

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

micha13:10:51

to clarify, merging boot-hoplon into hoplon does not make hoplon depend on boot in any way

micha13:10:35

just like a living library that has implementations for different loggers

alandipert13:10:57

in tihs case if they remained separate deps, i could independently update my boot-hoplon dep and still use the library

micha13:10:59

it wouldn't depend on every logger

micha13:10:17

that's what we want to avoid though

onetom13:10:24

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.

micha13:10:46

because than we need to have a compatibility matrix for boot hoplon

alandipert13:10:08

a compatibility matrix seems better than no compatibility story

alandipert13:10:49

it feels like a confus to merge two dependencies that have implications at separate 'phases'

alandipert13:10:00

since you suffer the other no matter what, end user has no leverage

micha13:10:01

i don't understand

alandipert13:10:11

the example above, how to solve?

micha13:10:19

which example?

micha13:10:00

it's exactly the same situation as we saw with boot and boot.jar

alandipert13:10:27

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

micha13:10:48

if there is innovation in hoplon we will make a new hoplon release

micha13:10:56

that will contain hoplon.core and the boot task

micha13:10:07

you just update your hoplon dependency

alandipert13:10:32

just spitballing here

alandipert13:10:51

so suppose i have an app that depends on hoplon/ui, which depends on hoplon 7.0 or whatever

alandipert13:10:23

hoplon/ui has nothing to do with the boot-hoplon task

alandipert13:10:30

it doesn't call it or use it any way, just drags it in

micha13:10:02

the same way logging frameworks drag in code for loggers you don't use

alandipert13:10:27

no it's not the same

micha13:10:28

you just don't require the namespaces you don't want

alandipert13:10:40

because usually those libraries depend on the logging frameworks as dependencies

onetom13:10:47

at runtime

alandipert13:10:49

it would be like if hoplon/ui depended on each of hoplon and boot-hoplon

alandipert13:10:58

then i could exclude boot-hoplon easily, the way i can exclude logging deps

micha13:10:58

not at all

micha13:10:15

exclusing boot-hoplon is unnecessary

micha13:10:25

because every hoplon includes a boot-hoplon

micha13:10:43

so if you are using boot-hoplon in your project, you will have a direct hoplon dependency

micha13:10:48

in your :dependnecies

micha13:10:00

otherwise you end up with a random version of hoplon

micha13:10:07

via transitive dependency

micha13:10:25

and this is exactly the situation that merging is helpful for

micha13:10:51

the thing we want to specifically prevent is someone using a newer version of boot-hoplon with an older version of hoplon

micha13:10:14

because then it is extremely difficult to maintain the compatibility matrix

micha13:10:19

and it's erally impossible

micha13:10:24

as we found with boot

onetom13:10:24

now that's a clear problem statement finally

micha13:10:26

and boot.jar

micha13:10:32

it's right there in the commit message 🙂

onetom13:10:50

err... which commit message?

alandipert13:10:07

i see, so the answer is, bug hoplon/ui to upgrade i foyu want to upgrade

micha13:10:23

just add your own hoplon dependency

micha13:10:26

which you should anyway

alandipert13:10:41

but what if it's not compatible with hoplon/ui

micha13:10:54

if it's newer and not a major version bump it will be

alandipert13:10:58

i guess it will always be backward compatible?

micha13:10:36

we definitely don't want to have to worry about compatibility across major versions between boot-hoplon and hoplon

micha13:10:38

that would be insane

onetom13:10:39

okay, i just checked the issues, not the pull requests before i created https://github.com/hoplon/boot-hoplon/issues/10 ... sorry

micha13:10:14

with boot.jar it was impossible to maintain compatibility

micha13:10:23

in practice

micha13:10:31

we were frequently breaking things

micha13:10:21

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

micha13:10:27

and we stopped breaking things that way

alandipert13:10:30

it seems like a different scenario, in boot the dependencies share an environment

alandipert13:10:52

like, everything in the boot runtime depends on what happened previously

alandipert13:10:02

vs. boot-hoplon, the mission of which is to compile into cljs

micha13:10:13

boot-hoplon is totally coupled to hoplon

onetom13:10:42

but it's not true the other way around, or is it?

micha13:10:03

that's why it makes sense to release a new version of boot-hoplon for each version of hoplon

micha13:10:30

because when hoplon changes it might require changes to boot-hoplon

micha13:10:34

but not vice versa

micha13:10:49

this is exactly the same as boot and boot.jar

onetom13:10:59

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...

micha13:10:15

right and you don't need to use it

micha13:10:43

there is nothing forcing you to require that namespace and put the hoplon task in your build pipeline

onetom13:10:52

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

micha13:10:18

if you don't like the boot-hoplon stuff you can just pretend it doesn't exist

micha13:10:33

there are tons of files you don't even know about in the jars you add to your classpath

micha13:10:40

this just adds a few more

onetom13:10:32

actually.... i do see them in intellij and that's why im a bit against lumping together code which serve very different purposes

micha13:10:07

you must see hundreds of thousands of files in intellij

micha13:10:15

jars contain all kinds of things

onetom13:10:32

thats why im constantly looking for alternative solutions... 😉

micha13:10:40

it would be a shame to organize dependencies based on the ui limitations of a specific IDE

onetom13:10:52

i didnt say that

onetom13:10:16

i just said that im very much aware of the amount of shit library developers put into the jars they deploy...

micha13:10:23

the specific problem that PR addresses is incom[patibility between hoplon and the boot tasks

micha13:10:56

currently we need to post a matrix of which version of boot-hoplon to use with a specific version of hoplon

micha13:10:14

so one way to simplify this is to synchronize the versions

micha13:10:28

each time we release a new version of hoplon we release boot-hoplon

micha13:10:32

and vice versa

alandipert13:10:32

did someone have this problem?

micha13:10:56

you should look at what i had to do in there

micha13:10:02

to try to maintain compatibility

micha13:10:13

i'm not very confident it's all really legit

micha13:10:25

sniffing for files in the classpath

micha13:10:39

case statements for what to do when various things are on the classpath or arent

alandipert13:10:49

that definitely doesn't seem like our job

micha13:10:50

programming logic for specific versions of hoplon etc

alandipert13:10:01

my concern tho is that by combining the deps we make it impossible for other people to do

micha13:10:09

what is impossible though?

micha13:10:16

using an incompatible version?

micha13:10:22

i don't see that as a bad thing

alandipert13:10:32

incompatibility isn't a single shoe

alandipert13:10:38

for some people it will work, for others it won't

micha13:10:45

i don't see how

alandipert13:10:49

by keeping the deps separate they can decide what to do based on their circumstances

alandipert13:10:03

like maybe the part of hoplon/ui i'm using that needs the old hoplon works just fine

micha13:10:09

a change to hoplon requires a change to boot-hoplon

alandipert13:10:11

like maybe it depends on the behavior of some multimethod in an old hoplon

micha13:10:32

as long as i don't have to manage the compatibility matrix

alandipert13:10:45

i propose this strawman

alandipert13:10:54

keep the deps separate, but make hoplon a dep of boot-hoplon

alandipert13:10:21

so if you just depend on boot-hoplon, you get a known-working setup

alandipert13:10:30

now if you start to depend on libraries that use old hoplons, you enter hell and that's on you

alandipert13:10:35

at least you can exclude bits

alandipert13:10:49

this is exactly how the logging things work (or don't)

micha13:10:24

logging things use DI

alandipert13:10:25

i dunno though, maybe it's better to couple them and force people to update

alandipert13:10:06

the DI works because they have initialize staticly and the names of the incompatible logging classes are the same

alandipert13:10:21

so if you depend on e.g. datomic which brings in logger foo 1.2.3 and aws brings in foo 1.3.1

alandipert13:10:37

your import of the class might do something different

alandipert13:10:55

since the logging things are named transitive deps you can exclude the one that doesn't work

alandipert13:10:46

maybe the logging thing is a bad example though, because those are libraries, and we want to be a framework

onetom13:10:01

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

alandipert13:10:02

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

alandipert13:10:48

yeah, definitely don't need to worry about boot-hoplon messing with your boot version

onetom13:10:14

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

onetom13:10:24

and it keep downloading a bunch of small pom files for earlier versions of the boot.core,pod,worker etc libs veeery slowly....

onetom13:10:14

i know it's not directly relevant to the current question, im just explaining why do i care about avoiding unnecessary code coupling

onetom13:10:27

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

onetom13:10:53

so keeping version numbers in lockstep and releasing packages solely with a version number bump might lead to such convergence

dm314:10:42

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.

alandipert14:10:38

would one depend on the other?

dm314:10:12

in Hoplon case - there's no need. Usually you'd have something like hoplon-tools that'd transform in a build-tool agnostic way

dm314:10:25

then boot-hoplon would depend on that

alandipert14:10:33

compilers i've seen on the jvm tend to have 2 deps, the compiler and the runtime

alandipert14:10:40

both same version, compiler depends on runtime

dm314:10:10

boot-hoplon only depends on names of things that are in hoplon

dm314:10:44

so there's no runtime dependency, right?

alandipert14:10:09

that's true, not necessarily

alandipert14:10:19

i think it's done to indicate which version of the runtime the compiler corresponds to

dm314:10:48

I see there's bust-cache

dm314:10:46

which could probably disappear from hoplon.core

dm314:10:52

then there would be no runtime dep

dm314:10:21

if the versions would always be in sync, there would be no question

dm314:10:29

you just release both every time

micha14:10:35

it just seems overly complicated to have two separate artifacts that the user needs to understand the relationships between

micha14:10:49

when there is no useful reason for using a mismatched version of boot-hoplon at all

micha14:10:08

as it is currently people just use the latest of both

micha14:10:13

and hope for the best

micha14:10:27

but this beraks things, as i'm sure has happened recently with boot-hoplon

micha14:10:40

since it's supporting a version of hoplon that has the jquery split

micha14:10:04

i put in some disgusting hacks to sniff the classpath to see if it's building an older version of hoplon

micha14:10:20

but i don't want to do that anymore, becuase i don't feel very confident that it can be done well

micha14:10:12

whenever hoplon.core is updated there could be changes that need to be made to boot-hoplon

dm314:10:53

@onetom did I understand right that you're using Hoplon completely without boot-hoplon?

micha14:10:17

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?

micha14:10:55

and also that boot-hoplon 0.3.0 might not work with hoplon 6.0.0-alpha16?

micha14:10:31

and what exactly is the benefit of having a separate boot-hoplon dependency?

dm314:10:52

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.

micha14:10:24

i don't see the logic there

micha14:10:45

what is the harm of having a few extra files in a jar that you can completely ignore if you want to?

dm314:10:06

that's why there's "feel strongly"

micha14:10:08

what you gain is not having to deal with dependnecy hell

dm314:10:19

there's not much logic

alandipert14:10:26

i would contest that this is in any way an escape from dependency hell

micha14:10:30

every java project in maven contains files you don't need

alandipert14:10:37

because there will still be libraries that depend on old versions

alandipert14:10:41

and will only work with them

micha14:10:11

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

micha14:10:41

if they don't depend on the correct version of boot-hoplon their build will berak

alandipert14:10:12

right, that's the way it is now, and i like it

micha14:10:18

if you depend on an old version of boot-hoplon and a new version oof hoplon then your build will just be broken

micha14:10:44

if that's what we like then we can continue that way of course

alandipert14:10:56

it seems like the main user unfriendliness here is the disparity between versions

alandipert14:10:03

if we just line them up, it's super easy to see and know

micha14:10:10

then it's redundant

micha14:10:20

if you say "always use version X of both"

alandipert14:10:23

no, because you retain the ability to exclude one or the other in weird scenarios

alandipert14:10:29

you lose this with a single artifact

micha14:10:36

that's a YAGNI situation for sure

micha14:10:50

if there is some weird scenario then we need to fix a bug

dm314:10:16

I'd start with - does Hoplon position itself as build-tool independent library?

micha14:10:31

hoplon is independent of build tooling

micha14:10:40

in any of these scenarios

micha14:10:36

i can't think of any situation where you'd need to exclude boot-hoplon from hoplon if you are using boot-hoplon

micha14:10:47

unless there is a bug in boot-hoplon, which we need to fix anyway

alandipert14:10:59

boot-hoplon doesn't depend on boot, but it won't work if your entrypoint wasn't boot

micha14:10:00

so in that case the user would downgrade hoplon until the bug is fixed

alandipert14:10:51

which seems to make it build-tool dependent?

micha14:10:00

not at all

micha14:10:13

remember, the API will be stable and backward compatible etc

micha14:10:33

meaning anything that works with hoplon X.0.0 will work with hoplon X.0.1

micha14:10:40

and same with boot-hoplon

micha14:10:01

the only thing that changes is when you have version X.0.0 of hoplon and version Y.0.0 of boot-hoplon

micha14:10:07

which will no longer be a thing

micha14:10:19

because we cannot manage that sanely

alandipert14:10:28

i agree there

alandipert14:10:49

so i guess in the hoplon/ui example

micha14:10:55

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

alandipert14:10:56

let's say hoplon/ui depends on hoplon X.0.0

micha14:10:58

and combine them

alandipert14:10:07

there's also no reason to do it

micha14:10:19

sure there is

micha14:10:39

transitive dependencies need to be managed by a human when you build

micha14:10:52

there are lots of ways depenedncy conflicts arise

micha14:10:18

and since there is only one valid version of boot-hoplon once hoplon version is selected, there is no point to the transitive dep

micha14:10:37

but there is the opportunity for maven to choose a different version and screw you

alandipert14:10:48

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

alandipert14:10:03

i wanna understand the hoplon/ui example

micha14:10:17

hoplon/ui depends rtansitively on hoplon

alandipert14:10:20

so let's say we have consolidated and in my app i depend on hoplon Y

micha14:10:25

you'd set that in your build.boot

alandipert14:10:27

but i use a hoplon/ui that depends on X

micha14:10:58

then if hoplon Y and X are not compatible you need to downgrde to X

alandipert14:10:04

suppose the hoplon runtime component in X and Y is compatible, incidentally

alandipert14:10:08

but the boot tasks are not

micha14:10:15

then no problem if they're merged

micha14:10:21

because you'll get the correct version

alandipert14:10:33

like X runtime works with Y, but Y task doesnt' work with X

alandipert14:10:43

or whatever the scenario would be where i can't make it work

micha14:10:49

that's fine because we're not using X

micha14:10:01

we're using hoplon Y plus the corerct boot-hoplon for Y

micha14:10:06

automatically

alandipert14:10:24

there is a problematic scenario here though isn't there?

micha14:10:32

that's exactly the reason why i want to merge them in fact

micha14:10:37

for that exact scenario

micha14:10:04

once you choose a version of hoplon you have implicitly chosen a version of boot-hoplon

micha14:10:11

so the separate dependencies is a sham

micha14:10:15

becaue they're not separate

micha14:10:30

there is only one correct version of boot-hoplon for a given version of hoplon

alandipert14:10:30

so i could eitehr choose to use the version that works with ui

alandipert14:10:37

or use Y and send a PR to ui for Y

micha14:10:12

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

alandipert14:10:26

it's related only because they share an artifact, it seems

alandipert14:10:35

it definitely would not be related at all if they were separate

micha14:10:43

hoplon/ui doesn't depend on anything related to boot-hoplon

micha14:10:12

having them separaet doesn't provide any separation

alandipert14:10:26

i guess that's because we don't ship .hl in libraries?

micha14:10:26

like i said, if you use hoplon X, you must use boot-hoplon X

micha14:10:47

if you use any other version of boot-hoplon you are in compatibility matrix land

alandipert14:10:47

i think i am beginning to Believe anew

micha14:10:52

which we do not want to support

micha14:10:03

maven has no such thing

micha14:10:22

there is no way to tell maven that a specific version of one thing demands a specific version of another thing

micha14:10:29

this is because you would just merge them then

micha14:10:34

if they are so tightly coupled

alandipert14:10:41

i see now why this is different than the usual compiler/runtime scenario with scala or whatever

alandipert14:10:55

because libraries don't contain input to boot-hoplon

micha14:10:03

or you can made different artifacts with the same id and version

micha14:10:09

like java does with the javadocs and source

micha14:10:19

but that seems unnecessarily complicated

alandipert14:10:45

it's hard to believe there isn't a single realistic scenario where you could benefit from being able to pick and choose

micha14:10:58

this is by design

micha14:10:05

we don't want to support that

micha14:10:27

keep in mind though that the API is different from the artifact

alandipert14:10:32

and you think this will be better for the library system in the long term?

flyboarder14:10:46

Actually we do ship hl files as it stands

micha14:10:52

the boot-hoplon API will be backward compatible

micha14:10:08

so anything you could do with boot-hoplon X.0.0 you can do with boot-hoplon X.0.1

micha14:10:19

so there is no valid reason to downgrade just boot-hoplon

alandipert14:10:35

ok i see now

micha14:10:43

unless, as i said, there is a bug in boot-hoplon X.0.1, which we need to fix anyway

alandipert14:10:14

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

micha14:10:32

and that's the way we can ensure the backward compatibility

flyboarder14:10:39

With the manifest option you need boot-hoplon anyway, if I write a library I now depend on both deps

alandipert15:10:07

@flyboarder any reason in particular you ship .hl instead of converting and then pushing?

flyboarder15:10:18

That breaks things

micha15:10:23

changes to the hoplon API yeah

micha15:10:28

it generates refers

micha15:10:37

which will fail if hoplon names change

micha15:10:49

we ran into this in the past

micha15:10:58

kind of like how cljs packages source and not js

alandipert15:10:12

i see, that's an unfortunate imposition of cljsc i suppose

alandipert15:10:16

it can't just friggen deal with it

flyboarder15:10:42

I just don't know if we want to deprecate a repo is all

flyboarder15:10:00

I'm fine with either way

micha15:10:59

i think supporting .hl files via the manifest is ok

flyboarder15:10:14

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?

micha15:10:55

we'd have the same problems there

flyboarder15:10:33

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

micha15:10:59

the numner of lines of code is the same either way

micha15:10:11

the only difference is how many artifacts the user needs to manage

micha15:10:31

and the management is not something the user has control over anywy

alandipert15:10:33

lein-hoplon would just need to uphold the backward-compatible contract

alandipert15:10:44

tha'ts like, the compiler contract i guess

alandipert15:10:49

the clojure whay

micha15:10:07

and that's way easier to do when we don't need to worry about forward compatibility

alandipert15:10:10

(in jack black voice whaay)

micha15:10:29

like "will this new version of hoplon beak things for people who don't upgrade boot-hoplon?"

alandipert15:10:40

absolute not

micha15:10:42

that's something i need to think about now, and it's not good

micha15:10:15

or "if someone upgrades boot-hoplon but not hoplon"

micha15:10:19

also impossible

alandipert15:10:39

yeah that's like cross-compiling and hoping it still works

flyboarder15:10:57

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?

flyboarder15:10:39

Since we are now fixing boot tasks and the hoplon core

micha15:10:06

it will require more releases to hoplon, yes

micha15:10:11

but no releases to boot-hoplon

micha15:10:26

so the same or fewer at the end of the day

micha15:10:49

and no issues like we have now with things in master that can't be released until the other is released

micha15:10:59

and a short time when things are broken in the middle

flyboarder15:10:09

Like I said I'm up for either way, just feel bad for the poor deprecated repo

alandipert15:10:25

we could deploy to them both lol

alandipert15:10:29

same exact artifact

micha15:10:36

but then the user needs to enforce that

micha15:10:41

and it's not even an option

flyboarder15:10:47

That might cause problems

micha15:10:56

they just need to know that maven could screw them sometimes and they will need to intervene

alandipert15:10:59

i guess our community is small enough we can just put hte word out

micha15:10:11

there is a warning in my PR

alandipert15:10:13

and things will hopefully be much more reasonable for the midterm

micha15:10:24

if you have boot-hoplon dependency it will warn you that it's not needed

micha15:10:32

and tell you to remove it

micha15:10:46

it will warn when you build your app

micha15:10:15

so we don't even need to make an announcement really

micha15:10:48

and the older versions of hoplon cotinue to work with whatever version of boot-hoplon you were using of course

dm315:10:43

it's worth noting that the merge works well because boot-hoplon doesn't drag a whole bunch of other dependencies

micha15:10:11

yes it does all of its deps in a pod

dm315:10:41

that's why in maven world you'd have it in a separate module

dm315:10:55

and if lein-hoplon appears, it'll probably work by invoking boot

flyboarder15:10:56

Well I thinks it's a convenient solution for people to have 1 dep and get all the hoplon awesomeness

micha15:10:32

the only alternative would be to have 2 maven artifacts and release both synchronized

micha15:10:52

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]

micha15:10:57

which seems redundant

flyboarder15:10:59

That could also work since after the first sync they should be compatible

dm315:10:02

yes, which would be the right thing to do if boot-hoplon had a lot of deps

micha15:10:08

because there is nothing else they could type there and be correct

flyboarder15:10:12

I guess having different major versions only adds to the confusion

flyboarder15:10:23

The more I think about ways to keep boot-hoplon compatible with hoplon, the more merging is just easier all around

flyboarder16:10:37

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

flyboarder16:10:04

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.

flyboarder16:10:05

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

micha16:10:55

if we do that then there is more need to merge them

micha16:10:13

because then the choice of boot-hoplon is really tightly coupled to the version of hoplon

micha16:10:07

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

flyboarder16:10:24

But not if we remove the hoplon.jquery include, then the existing boot-hoplon still works

micha16:10:32

because the user is forced to maintain the correct versions on their own end, but there is only one correct choice

micha16:10:03

no, what happens if you use a different version of boot-hoplon with a version of hoplon that doesn't have jquery by default?

micha16:10:07

your build breaks

flyboarder16:10:33

Right but you are only missing attributes, so you refer the correct provider

micha16:10:40

the default inclusion of hoplon.jquery was to provide backward compatibility

micha16:10:51

no, that doesn't work

micha16:10:02

because then lder versions of hoplon will be broken

micha16:10:09

they don't have that namespace

micha16:10:29

currently boot-hoplon sniffs the classpath to see if hoplon.jquery namespace exists

micha16:10:36

and includes it if it does by default

micha16:10:48

that provides backward compatibility with older versions of hoplon.core

micha16:10:17

this is exactly what we want to avoid i think

flyboarder16:10:48

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

flyboarder16:10:59

If a user has to make additional changes anyway, then we need an upgrade guide

flyboarder16:10:27

But the only real change is the attribute provider not being in core anymore

flyboarder16:10:25

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

micha16:10:06

i want to maintain backward compatibility of the API when possible

micha16:10:27

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

micha16:10:43

i don't see any benefit to breaking people's apps that use jquery

micha16:10:56

if you don't want to use jquery then you ad your requires or whatever

micha16:10:05

that's not a breaking change

flyboarder16:10:21

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?

micha16:10:37

you should be able to

flyboarder16:10:09

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

micha16:10:34

removing a dependency is easy, you're told exactly what to do

micha16:10:02

and the current version of boot-hoplon will actually work with hoplon

micha16:10:11

so even if you don't remove it you're ok

flyboarder16:10:43

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?

micha16:10:05

we could, yes

micha16:10:14

but the warning would always say the same thing

micha16:10:22

it would be just making busywork for the user

micha16:10:38

like if you have a light switch

micha16:10:48

and on the other end of the room is another light switch

micha16:10:04

and when you flip one it tells you to flip the other too

micha16:10:18

you could just combine the two switches with some duct tape

micha16:10:26

and save the user some pointless work

flyboarder16:10:54

Right, again I'm all for merging, just trying to explore the options

flyboarder16:10:55

I think for user adoption having 1 dep regardless of useless files being in the jar is the simplest of solutions

flyboarder16:10:26

For most people they will probably use the boot task anyway

micha16:10:44

i want it to be safe to update hoplon to a newer minor version without needing to change any application code

micha16:10:08

and without needing to spelunk through compatibility matrices

flyboarder16:10:16

Agreed, if we make breaking changes we should make all of them now with the next major

micha16:10:32

and then we must only deprecate things, as @mynomoto says

micha16:10:30

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

micha16:10:16

that is to say, a major version release is simply removal of deprecated features

micha16:10:32

not the addition of new or incompatible features

flyboarder16:10:10

Right, my only concern is the deprecation of an entire repo, but you and @alandipert are the ones you have to maintain that 😜

micha16:10:36

haivng fewer dependencies is i think a good thing for the user

flyboarder16:10:20

Agreed, it just might be confusing for newcomers that there is a boot-hoplon repo but that's why I made the deprecated badge

micha16:10:35

yeah plus the message you get when you build

micha16:10:47

the warning is i think pretty straightforward

flyboarder16:10:04

Yeah I guess by version 8 or 9 the repo could be deleted without anyone noticing

micha16:10:19

we could totally delete the repo on github

micha16:10:28

the stuff in clojars will be there for eternity

micha16:10:41

so anyone with older builds is still fine

flyboarder16:10:43

If you are all fine with this stuff then we should start to document the deprecated stuff in a road map

micha16:10:07

yes @mynomoto has listed some things that should be removed from hoplon

micha16:10:26

we should all agree on those, i think

micha16:10:55

the hoplon project has accumulated various cljs hacks that may or may not want to include in hoplon itself

micha16:10:21

we should discuss this and come to some sort of consensus on what we want to do there

flyboarder16:10:38

Are the things in a ticket somewhere already? Or just the ns+ one?

micha16:10:01

i believe there are a few tickets with comments

micha16:10:21

maybe we make a "stuff we want to remove from hoplon" card?

flyboarder16:10:10

Sounds good, I think we should add the http://Waffel.io integration if we are going to start using a real task mgmt system

flyboarder16:10:50

Waffel bot added

vigilancetech19:10:31

is there a hoplon/ui canvas example?

vigilancetech22:10:16

ok. I saw that line where the canvas primitive was created. Would a similar line do svg?

jumblerg22:10:57

where with-let is a hoplon util that returns the element in the let binding after the mutations

vigilancetech22:10:33

right, I remember reading about that the other day. Wasn't exactly sure where/when to use it tho. thx!

jumblerg22:10:49

i don’t have an svg constructor in ui yet, but i’ll add one tonight

jumblerg22:10:03

should be pretty straigtforward

jumblerg22:10:23

i had one before, but there should be one like the rest of the ui media elements

jumblerg22:10:42

i’m currently working on the markdown parser

vigilancetech22:10:01

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.

vigilancetech22:10:42

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.

jumblerg22:10:58

i’ll send you the link to one

vigilancetech22:10:19

worked good but I couldn't get them to loop nor have the control bar be functional (but it showed up).

jumblerg22:10:42

ahhh, i know why that is happening

jumblerg22:10:49

i have a fix for this i haven’t pushed

jumblerg22:10:05

there’s an invisible elem over them catching all the events

vigilancetech22:10:21

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?

jumblerg23:10:16

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 Elem type.

jumblerg23:10:54

it would work for a hoplon/hoplon canvas, like:

(with-let [canvas-elem (hoplon.core/canvas :css/width 400 :css/height 400)]
  (doto (.getContext canvas-elem "2d")
        (.moveTo 50 50)
        (.lineTo 100 100)
        (.stroke)))