[Neuroimaging] Website Update

Sun Aug 23 02:08:54 CEST 2015

My current strategy is to use Jekyll plugins to try and set either the
site.baseurl, or a "baseurl" variable, based on, say, environment variables
(circle.ci) or the site object (github).

It's easy to set variables, easy to get environment variables, sometimes ok
to get the site object... but haven't got it all together yet.

Some references:
https://circleci.com/docs/environment-variables
https://help.github.com/articles/repository-metadata-on-github-pages/

http://jekyllrb.com/docs/plugins/
http://ruby-doc.org/core-2.1.4/ENV.html

and according to this:
http://jekyllrb.com/docs/variables/
you can't reset values of the site.baseurl value, so probably will have to
store a separate variable in some other structure, and use that elsewhere.

Ben

On Sat, Aug 22, 2015 at 12:56 PM, Ben Cipollini <bcipolli at ucsd.edu> wrote:

> @Ariel I don't think that change solves anything different than simply
> setting the baseurl to /nipy-jekyll/ (note: I would avoid the fully
> qualified URL, it would unintentionally make a circle.ci version of the
> site, or a locally built one without specifying an overriding baseurl, to
> pull from an unexpected source.)
>
> The problem is (at least as I see it), we need different baseurl values
> for different build situations (gh-pages, circle.ci, local).
>
>
> On Sat, Aug 22, 2015 at 12:12 PM, Ariel Rokem <arokem at gmail.com> wrote:
>
>>
>> On Sat, Aug 22, 2015 at 11:34 AM, vanessa sochat <vsochat at stanford.edu>
>> wrote:
>>
>>> The "ugly" solution is to use different templates for the pages not at
>>> the base url, and then you can just hard code the page one level up. For
>>> example, in the header
>>> <https://github.com/vsoch/nipy-jekyll/blob/master/_includes/head.html>:
>>>
>>> a path currently looks like:
>>>
>>> <script src="{{ "js/tipsy.js" | prepend: site.baseurl }}"></script>
>>>
>>> and for subpages, we would make a new header_subpage.html with a path
>>> like:
>>>
>>> <script src="{{ "../js/tipsy.js" | prepend: site.baseurl }}"></script>
>>>
>>> But then when you change anything about the design, you have to change
>>> it in two places. I started implementing this, felt sick to my stomach at
>>> how awful the idea was, and completely converted everything back :) I think
>>> it could be possible to use this weird language
>>> <http://liquidmarkup.org/> so that all pages detect their level. For
>>> example, take a look here
>>> <https://github.com/vsoch/nipy-jekyll/commit/2ac70c6dee2372be6676848aac9766459f4c57c2#diff-e921a390257abd15c1742300f2417b13R14>
>>> at a solution I figured out using the syntax - but it fails in that the if
>>> statement is hard coded.
>>>
>>> Also take a look here
>>> <https://github.com/vsoch/nipy-jekyll/commit/c72756afad2bc4cb57d893f76e9dd4f425b79218#diff-4ea7a794e4d7b7503ac520689daeb20bL17>
>>> - for the posts we can get the URLs programatically, but I wasn't sure how
>>> to do that for "non-post" pages.
>>>
>>>
>>>
>> I am also thinking in this direction. Maybe we can have different baseurl
>> configs for different things? Something along these lines:
>>
>>
>> https://github.com/arokem/nipy-jekyll/commit/9f2b6be741b20b779321dc2739fc6c6efa1a3bac
>>
>> Still not working, but something like this might work. Once we settle on
>> a design, I don't expect that we will have many changes there. I think that
>> most PRs will be with text content, and not to things of this sort, so I am
>> not too worried about the potential ugliness of having to change many
>> things in many places for that.
>>
>>
>>
>>
>>
>>> On Sat, Aug 22, 2015 at 11:24 AM, Ben Cipollini <bcipolli at ucsd.edu>
>>> wrote:
>>>
>>>> Oops, I spoke too soon. Sounds like circle.ci is very important. :)
>>>>
>>>> Vanessa, you had an idea for an "ugly" solution for the original issue?
>>>> May I ask what that is? Looks like others are simply using --baseurl="" on
>>>> the command-line.
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>>
>>>> On Sat, Aug 22, 2015 at 11:19 AM, vanessa sochat <vsochat at stanford.edu>
>>>> wrote:
>>>>
>>>>> Hi Ariel,
>>>>>
>>>>> Circle is needed to preview PRs.
>>>>>
>>>>> On your fork take a look at the individual blog pages - the path goes
>>>>> to the base and it is not found. And then on circle since the baseurl is
>>>>> "/" it would be quite broken looking.
>>>>>
>>>>> Right now adding a project would mean adding an entry to the data file
>>>>> <https://github.com/vsoch/nipy-jekyll/blob/master/_data/packages.yml>,
>>>>> and then copying a template page for it (for example
>>>>> <https://github.com/vsoch/nipy-jekyll/blob/master/sdm.html>, you
>>>>> would just need the header and to name the page corresponding to its tag in
>>>>> the data file). The navigation, front page, and D3 are rendered from that
>>>>> file, but I didn't see a nice way to generate an entire page for the
>>>>> package. The reason I had originally chosen flask is because a person could
>>>>> just add a line to a tsv file, and the application would be smart enough to
>>>>> make the page if the user did not. I don't see a way to achieve that with
>>>>> these more syntax based frameworks.
>>>>>
>>>>> For the content and more tweaks to the design - let's hold off on
>>>>> jumping into that until we get this url issue worked out! I am totally game
>>>>> for adjusting the design, layout, content for whatever people think is best.
>>>>>
>>>>> Best,
>>>>>
>>>>> Vanessa
>>>>>
>>>>> On Sat, Aug 22, 2015 at 11:04 AM, Ariel Rokem <arokem at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Vanessa,
>>>>>>
>>>>>> Sorry for the delay in responding.
>>>>>>
>>>>>> On Sun, Aug 16, 2015 at 3:18 PM, vanessa sochat <vsochat at stanford.edu
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi Everyone,
>>>>>>>
>>>>>>> Here is an update to the site. I've ported it into jekyll
>>>>>>> <https://github.com/vsoch/nipy-jekyll>, and tested the template on
>>>>>>> iphone and computer (seems reasonable). I've also gotten it to render the
>>>>>>> artifacts on circle.ci
>>>>>>> <https://circleci.com/gh/vsoch/nipy-jekyll/32>, so we could preview
>>>>>>> PRs (Click "artifact" and then find home.html
>>>>>>> <https://circle-artifacts.com/gh/vsoch/nipy-jekyll/32/artifacts/0/home/ubuntu/nipy-jekyll/_site/home.html>).
>>>>>>> However, I've run into a bug with regard to absolute vs. relative paths -
>>>>>>> when you click the demo link above, the "posts" not being at the base url
>>>>>>> means they will not be linked or render correctly (for example, here
>>>>>>> is a link
>>>>>>> <https://circle-artifacts.com/gh/vsoch/nipy-jekyll/32/artifacts/0/home/ubuntu/nipy-jekyll/_site/code-syntax/index.html>
>>>>>>> to a post on circle, and you won't see styling because the css/js links are
>>>>>>> broken)
>>>>>>>
>>>>>>> The site works perfectly given that we aren't serving it at a
>>>>>>> relative path, eg:
>>>>>>>
>>>>>>> jekyll serve --baseurl="/"
>>>>>>>
>>>>>>> And the challenge is finding a solution that will render locally, on
>>>>>>> github pages, and circle.ci, and what we need, I think, is some
>>>>>>> kind of liquid syntax that will detect when we are in a subfolder and
>>>>>>> render appropriately. I've been messing around with it for 7 hours today
>>>>>>> and can't figure it out, and I need to ask for help. Could someone else
>>>>>>> take a look? Likely someone with more experience than me with Jekyll could
>>>>>>> figure this out in a heartbeat (Ariel?) The plan right now, I'd like to
>>>>>>> propose, would be to figure out this bug, get it onto a (test) github
>>>>>>> pages, tweak the details of the content, make proper documentation, and
>>>>>>> then release to official github pages.
>>>>>>>
>>>>>>>
>>>>>> Why do we need CircleCI here? I am actually not sure what the issue
>>>>>> is, but here's the site rendered through gh-pages on my fork of your repo:
>>>>>>
>>>>>> http://arokem.github.io/nipy-jekyll/
>>>>>>
>>>>>> I did also add a Gemfile to the repo, and that might matter: I
>>>>>> believe Github pages serves jekyll through a call to "bundle exec jekyll
>>>>>> serve" (see here:
>>>>>> https://help.github.com/articles/using-jekyll-with-pages/).
>>>>>>
>>>>>> One comment about the content: I would prefer to have a front page
>>>>>> that just states what this thing is, and the projects on a separate page. I
>>>>>> would like for it to be *super* easy to add projects. The whole idea is
>>>>>> that the NIPY community is not a static list of projects, but an
>>>>>> ever-evolving ecosystem.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ariel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Vanessa
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Vanessa Villamia Sochat
>>>>>>> Stanford University
>>>>>>> (603) 321-0676
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Neuroimaging mailing list
>>>>>>> Neuroimaging at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Neuroimaging mailing list
>>>>>> Neuroimaging at python.org
>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Vanessa Villamia Sochat
>>>>> Stanford University
>>>>> (603) 321-0676
>>>>>
>>>>> _______________________________________________
>>>>> Neuroimaging mailing list
>>>>> Neuroimaging at python.org
>>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Neuroimaging mailing list
>>>> Neuroimaging at python.org
>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>
>>>>
>>>
>>>
>>> --
>>> Vanessa Villamia Sochat
>>> Stanford University
>>> (603) 321-0676
>>>
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>
>>>
>>
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150822/ab53edd2/attachment.html>