Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2018-08-02

Channels

#cljsjs
<
2018-08-02
>
jsa-aerial14:08:51

@juhoteperi I think you are the most likely to know this - I have now updated the packages for vega, vega-lite, vega-embed and vega-tooltip. These are all versions in support of the final release 3 of vega and release 2 of vega-lite. Newer are now dev rc versions.

jsa-aerial18:08:37

@miikka Could you perhaps know the answers to these? Thanks.

jsa-aerial14:08:59

@juhoteperi before I commit, should I remove the target directories? Second, should I make four separate commits or all updates in one?

jsa-aerial18:08:04

@miikka Dang, these were the actual questions...

miikka18:08:03

@U06C63VL4 Yes, you should remove the target directories. And probably better for clarity to have separate commits.

jsa-aerial18:08:12

@miikka Thanks for the answers! I will remove the target dirs and make the separate commits. Should these also be separate pull requests or a single with the multiple commits?

miikka19:08:02

I guess a single PR is fine.

jsa-aerial01:08:03

@miikka I think there is something I do not understand about what the deps in the build.boot files mean. I am getting the error org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact cljsjs:vega:jar:3.3.1-0 in clojars (), but that's because this 'commit' is supposed to build that (and the other new version) jars and deploy them there. So, I must have a kind of chicken/egg confusion about what the deps in the build files mean. I'm not a boot guy, so that may be a contributing factor...

jsa-aerial19:08:43

@miikka I have a guess as to what this problem is. If there are dependencies as: vega <- vega-lite, vega <- vega-embed, vega-lite <- vega-embed, and vega <- vega-tooltip, then it looks like the integration tests require that vega (3.3.1) needs to be literally deployed to clojars before any of the rest have a chance to pass, and that vega-lite also needs to be deployed to clojars before vega-embed has any chance to pass. Such deployment appears to happen on successful PR resolution. So, it looks like these cannot be done with a single PR. There needs to be one for vega first, then one for vega-lite next, then one for vega-embed after that. While vega-tooltip could also be done after vega, probably best as a final PR. Does this make sense?

miikka08:08:36

Yes, you're right, sounds good. I didn't realize that there's the chain of dependencies for the libraries.

jsa-aerial15:08:52

@miikka OK, it looks like we are on the right track - vega PR passed all checks. Does a 'blessed' maintainer need to now close the pull or do I close it and then a blessed maintainer merges and that is when clojars will be updated. I don't want to start adding vega-lite until I know this vega is totally completed as it will fail. Thanks for any info - thanks for patience - this is the first time I'm doing this...

miikka16:08:10

Do not close it, a maintainer will merge it. I don’t have time today anymore, but I’ll check it tomorrow.

jsa-aerial16:08:30

✔️ Thanks!

jsa-aerial19:08:43

@miikka I have a guess as to what this problem is. If there are dependencies as: vega <- vega-lite, vega <- vega-embed, vega-lite <- vega-embed, and vega <- vega-tooltip, then it looks like the integration tests require that vega (3.3.1) needs to be literally deployed to clojars before any of the rest have a chance to pass, and that vega-lite also needs to be deployed to clojars before vega-embed has any chance to pass. Such deployment appears to happen on successful PR resolution. So, it looks like these cannot be done with a single PR. There needs to be one for vega first, then one for vega-lite next, then one for vega-embed after that. While vega-tooltip could also be done after vega, probably best as a final PR. Does this make sense?