#readthedocs

ericholscher, I see that that when running npm intall I get a bunch of deprecated warnings

are these defined by a file in the repo? I am not finding the file if that is true

Blendify_: believe the package.json:" https://github.com/rtfd/sphinx_rtd_theme/blob/m...

hmm do not think so. one of them is minimatch

which is not found in a grep of the repo

the others are win-spawn and graceful-fs

might be dependencies

npm loves dependencies

agj would be the one to ask though, I don't fully know it :)

could probably use a round of package upgrades

ericholscher, I think it would make it a lot simpler if running grunt build should be part of the release process

having to deal with merge conflicts with generated code is not that fun

for https://github.com/rtfd/sphinx_rtd_theme/pull/371 I am going to commit then run it

Blendify_: those are dependencies from our requriements

is there any tooling around automating package releases in python? something like distzilla for perl.

i think it makes sense as a release step, though we need to be on top of releases in that case

ie - get in the habit of dev releases

if we didn't have to put our password in the .travis.yml file, i'd say we could handle pypi and github releases there

not sure how i feel about that

there is also .gitattributes, but i only know of the feature, not sure if it would be applicable here

travis has encryption stuff for this

so you can encrypt your creds w/ their keys

but yea, +1 on adding it as a release step and removing it from the repo :)

is there a delay on the bot?

bot doesn't post for the theme here

ah... That makes sense

ericholscher: yeah, i know of the encryption on keys, still bothers me posting creds to github :)

probably not a huge issue if we really wanted that way though

go proper ci

ericholscher, is there a public number for the number of projects hosted on readthedocs?

Blendify_: https://blog.readthedocs.com/read-the-docs-2016...

cool thanks

ericholscher, what do you think of https://github.com/rtfd/sphinx_rtd_theme/pull/370 ?

ericholscher, can be https://github.com/rtfd/sphinx_rtd_theme/issues... be closed?

as far as I know we are using up to date font awesome

looks like we are using 4.6 and latest is 4.7

ericholscher, should I uses branches on the main repo or make a fork?

Blendify_: either works

agj, I think I will just keep it in the main repo

roger

less work...

on #266, not sure it buys us anything but more work. +1 on closing that

humitos: hey, missed your question the other day, my irc bouncer wasn't doing its job

humitos: you still have questions?

agj: hi, I'm about to go bed now

let's talk tomorrow

humitos: sure thing! talk to you tomorrow

!m

Added some demo docs of things that have given me issues before

ericholscher, around?

Blendify: aye

what do you think about https://github.com/rtfd/sphinx_rtd_theme/issues...

also what about adding an html logo to the demo docs?

something like https://media.readthedocs.com/corporate/img/hea...

although that might be too wide

maybe http://blog.readthedocs.com/_static/logo.png

hrm

html logo seems fine on demo docs

I'd like to better support that use case in general

re: submoduleing -- that's tricky, we should probably not officially support it

esp. if we're gonna switch to rendering the css on build, that kinda kills the submodule approach implicitly

ericholscher, do you have an opinion on which image I should include in the repo to use?

the one from the blog looks good

ericholscher, the other one looks better actually...

sure -- not a strong preference

i'm about to head to bed -- but thanks again for your work!

o/ I should do the same considering you on the other side of the states then I

Latter today I will do more bug fixes

sounds good

humitos: re conda: I _think_ all we need to do is rebuild the current image, which will update the conda version

yeah, that would work

because the docker image is downloading always the latest one

yea

but, are you thinking on re-build the 2.0 version? because the latest one has other changes also...

so, the 2.0 being re-built should be called 2.1 :) haha

heh

I think agj is probably the best to answer that stuff -- I haven't had much hand in setting up the docker hub stuff to this point

I triggered a rebuild of 2.0, which if that isn't using a cache, should hopefully fix it

I believe 2.0 should be a tag, so it won't get the changes -- but should install the latest version of conda, because it isn't pinned

https://hub.docker.com/r/readthedocs/build/buil... seems to be the rebuild

but it isn't showing any logs

ericholscher: checked, you should have access to the docker hub org

mmm... I'm not sure that docker pull readthedocs/build:2.0 will bring the new one, because it's the same tag

we can find a way to force it

yea, https://hub.docker.com/r/readthedocs/build/buil... is rebuilding

a random thread I found said they run it with `--no-cache`, so it should rebuild the conda version to latest

yup

we should be fixing this by pinning the installed version of conda instead, if anyone know of that

this is all a symptom of installing from shell script

looks like there are images other than 'latest': https://repo.continuum.io/miniconda/

great!

that should be the way of pinning the conda version in the docker image, then

aye

taking advantage of this situation, I want to ask: what's the correct label for that specific issue? :)

Blend|away ericholscher: with building on release, we'd still have artifacts checked in, that won't change. too make folks pinning sphinx_rtd_theme to our repo instead

humitos: which issue? i'm just getting caught up this morning before heading to the office

the one related to conda build and upgrading the image

my latest PR is ready for review

humitos: for something like that "operations" and "bug"

Blendify: best logo to use: https://github.com/readthedocs/guidelines/blob/...

probably better as a png

bleh

the rebuild still used installing: conda-4.3.11-py27_0 ...

guessing we should patch the image to explicitly install conda

agj: do we need to retag the builds?

branch 2.0 into 2.1?

thanks agj

ericholscher: you'll have to patch rtfd/readthedocs.org with the build image name, in doc_environment/constants.py

wonder if we should be using docker image metadata there actually, hrm

for simplicity, we can reuse tags, that's fine

I'm -1 on reusing tags, generally

not sure we need to get down to bug fix release minor versions on the images

seems confusing

why?

because its a tag, and if it changes over time, there isn't a way to know what version was what

for software packages i'm more strict, but we're one of the only consumers of this package

if we had a dynamic pattern in rtfd/readthedocs.org, i'd say we should be strict here too

that is, each version of the image we release requires patching rtd currently

the image metadata lookup needs to be a bit stronger

docker image labels could be a way to solve this though, i hadn't thought of that

inspect the image used for python support, instead of a dict lookup

fastest solution is to reuse 2.0 tag though

ooor

change dict lookup to a version compare lookup, which fails for `latest` of course

running to a lunch thing, but reusing 2.0 makes sense -- though I'm still not convinced we know what the actual issue is

downgrading conda seems like the simplest fix, since it used to work