Regarding project "Refactor and Automate Infusion Documentation"

Yash Jipkate yashjipkate at gmail.com
Mon Mar 16 15:21:59 UTC 2020


Hi Justin,

I noticed that in the current setup we use front matter to specify the
title of the page. But since we need to migrate all SSG related data, this
would mean that front-matter should not be present in the content files.
But not all titles can be automated in pre-configured front-matter. For
example, MInimalFootprint.md
<https://github.com/fluid-project/infusion-docs/blob/master/src/documents/tutorial-prefsFrameworkMinimalFootprint/MinimalFootprint.md>
has
the title 'Preferences Framework: Minimal Footprint' which can not be
referred from its filename as was my plan for possible automation. Should
we allow the title in the front matter in the content repo? I personally
suggest that we should keep it since irrespective of the framework used,
the title is something that is common to all SSGs' front-matter.

What do you think about it?

Thanks
Yash


On Thu, Mar 12, 2020 at 7:22 PM Justin Obara <obara.justin at gmail.com> wrote:

> Hi Yash,
>
> Sounds good.
>
> Thanks
>
> On Mar 12, 2020, at 9:27 AM, Yash Jipkate <yashjipkate at gmail.com> wrote:
>
> Hi Justin,
>
> I too think that we might have gone too deep into implementation details.
> I will try to keep my discussion to immediate doubts and parts of the
> codebase that I am facing difficulties with. Thanks for pointing out.
>
> Thanks.
> Yash
>
>
> On Thu, Mar 12, 2020 at 5:39 PM Justin Obara <obara.justin at gmail.com>
> wrote:
>
>> Hi Yash,
>>
>> Please see replies below
>>
>> Thanks
>> Justin
>>
>> On Mar 12, 2020, at 2:06 AM, Yash Jipkate <yashjipkate at gmail.com> wrote:
>>
>> Hi Justin,
>>
>> I have replied inline, I also had some questions regarding the project.
>>
>>    - What is the current method of deployment of the docs? There are
>>    lines like this
>>    <https://github.com/fluid-project/infusion-docs/blob/05bba0b6e2509241b13d4b5c50656914b1e30314/src/layouts/default.html.handlebars#L64> in
>>    the infusion-docs repo that uses relativeUrl to access something not
>>    included in the repo. From what I understand from the urijs docs,
>>    relativeUrl gets the relative URL of the argument w.r.t the current URL.
>>    But there is no such folder in the repo. In the link that I mentioned, the
>>    path is of the main infusion repo which is hosted somewhere else. How is
>>    the relative URL working if they are hosted differently?
>>
>> It looks like they are being copied to the correct location by the
>> copyDeps
>> <https://github.com/fluid-project/infusion-docs/blob/master/docpad.js#L69-L112> function
>> in docpad.js. They are originally pulled in as dependencies listed in the
>> package.json
>> <https://github.com/fluid-project/infusion-docs/blob/master/package.json#L15-L32>
>>  file.
>>
>
> It seems that it is a way of managing external dependencies. I found this
> blog <https://janaksingh.com/blog/hugo-package-management-folder-mounts/> that
> describes how to do this in HUGO.
>
>>
>>    - Since the migration is not incremental, how should this be carried
>>    out? I cannot modify the structure of the documents to HUGO-friendly and
>>    expect DocPad to keep running. One way to make this happen is to have a
>>    fork of the docs repo and then carry out the modifications there and merge
>>    it only when it is in a deployable state, i.e. when the HUGO repo is also
>>    ready. What do you think?
>>
>> Yes, you should be doing your work in a separate branch. It probably
>> makes sense to start off with some mock content, that is something small to
>> work with to get the pieces sorted out.
>>
>
> So, I would make a smaller version of the docs website with just a few
> docs and complete it with the corresponding HUGO code as well and then add
> the rest of the docs.
>
>>
>>    - Do we change the design of the site? There are many good themes
>>    available on HUGO which are ready to use. We can use them for the site and
>>    would give it a new look. If we don't change the design of the site then a
>>    custom theme needs to be built from scratch.
>>
>> I think for now expect that we’ll keep the same site design, but this is
>> something that can be discussed and researched as well.
>>
>>
>> Thanks.
>> Yash
>>
>>
>>
>>
>> On Wed, Mar 11, 2020 at 6:15 PM Justin Obara <obara.justin at gmail.com>
>> wrote:
>>
>>> Hi Yash,
>>>
>>> As usual comments below.
>>>
>>> Thanks
>>> Justin
>>>
>>> On Mar 10, 2020, at 3:05 PM, Yash Jipkate <yashjipkate at gmail.com> wrote:
>>>
>>>
>>> Hi Justin,
>>>
>>> Responded inline.
>>>
>>> Thanks.
>>> Yash
>>>
>>>
>>> On Tue, Mar 10, 2020 at 9:52 PM Justin Obara <obara.justin at gmail.com>
>>> wrote:
>>>
>>>> Hi Yash,
>>>>
>>>> Comments below.
>>>>
>>>> Thanks
>>>> Justin
>>>>
>>>> On Mar 10, 2020, at 11:40 AM, Yash Jipkate <yashjipkate at gmail.com>
>>>> wrote:
>>>>
>>>> Seems like the previous mail got sent in plain text mode. Therefore,
>>>> the hyperlinks vanished. I am sharing the links below.
>>>>
>>>>
>>>>    - Archetypes in HUGO
>>>>    <https://gohugo.io/content-management/archetypes/>
>>>>    - Angular <https://angular.io/docs> and React
>>>>    <https://reactjs.org/docs/getting-started.html> docs
>>>>    - Static file management in HUGO
>>>>    <https://gohugo.io/content-management/static-files/>
>>>>
>>>>
>>>> Thanks.
>>>> Yash
>>>>
>>>>
>>>> On Tue, Mar 10, 2020 at 8:57 PM Yash Jipkate <yashjipkate at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Justin,
>>>>>
>>>>> I have left some comments inline. Also, I'll be sharing the draft
>>>>> proposal soon.
>>>>>
>>>>> Thanks.
>>>>> Yash
>>>>>
>>>>>
>>>>> On Tue, Mar 10, 2020 at 5:37 PM Justin Obara <obara.justin at gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > Hi Yash,
>>>>> >
>>>>> > I’ve left some more comments below.
>>>>> >
>>>>> > Thanks
>>>>> > Justin
>>>>> >
>>>>> > On Mar 10, 2020, at 2:21 AM, Yash Jipkate <yashjipkate at gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > Hi Justin,
>>>>> >
>>>>> > Thanks for the reply. I have responded inline.
>>>>> >
>>>>> > Also, since the student application period approaches, should I
>>>>> start on my draft proposal using HUGO as the SSG? Since I have found it as
>>>>> the best alternative till now. If we find any other better alternative,
>>>>> then we can switch. But according to me, HUGO is best suited for our needs.
>>>>> >
>>>>> >
>>>>> > This would be up to you. You’re welcome to propose what you think is
>>>>> best. You might want to consider adding steps for investigation,
>>>>> experimentation and leaving things open to change.
>>>>> >
>>>>> >
>>>>> > Thanks.
>>>>> > Yash
>>>>> >
>>>>> >
>>>>> > On Tue, Mar 10, 2020 at 4:26 AM Justin Obara <obara.justin at gmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >> Hi Yash,
>>>>> >>
>>>>> >> Some comments inline below.
>>>>> >>
>>>>> >> Thanks
>>>>> >> Justin
>>>>> >>
>>>>> >> On Mar 9, 2020, at 4:32 PM, Yash Jipkate <yashjipkate at gmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >> Hi Justin,
>>>>> >>
>>>>> >> Thanks for the reply. I have responded inline.
>>>>> >>
>>>>> >> Thanks
>>>>> >> Yash
>>>>> >>
>>>>> >>
>>>>> >> On Mon, Mar 9, 2020 at 6:51 PM Justin Obara <obara.justin at gmail.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> Hi Yash,
>>>>> >>>
>>>>> >>> Somewhere along the line we lost our CC to the fluid-work mailing
>>>>> list. I’ve added that back in now so that others can follow along and
>>>>> provide input as needed.
>>>>> >>>
>>>>> >>> Another tool to look at would be https://docusaurus.io. It would
>>>>> be good to also investigate if there are other options/solutions that we
>>>>> haven’t yet mentioned.
>>>>> >>
>>>>> >>
>>>>> >> A complete list of all the major static site generators can be
>>>>> found at StaticGen. The list is sorted on the basis of recent trends in the
>>>>> community. Regarding Docusaurus, I found this blog that compares HUGO and
>>>>> Docusaurus. There is also this comment in an issue that compares Jekyll,
>>>>> Docusaurus, and HUGO. I read the Docusaurus docs and there are some
>>>>> advantages that it provides over the other SSGs.
>>>>> >>
>>>>> >> In-built versioning
>>>>> >> Translations
>>>>> >> Inbuilt search feature using Algolia.
>>>>> >>
>>>>> >> To summarize all the findings over the course of this thread, the
>>>>> various SSGs and their details are:
>>>>> >>
>>>>> >> HUGO
>>>>> >>
>>>>> >> Written in Go, therefore fast build times - countered by the fact
>>>>> that Go deprives us of npm packages and build times are not that big a
>>>>> concern to us.
>>>>> >> The search functionality needs to be manually implemented by the
>>>>> ways described here.
>>>>> >> Versioning can be realized by the usage of tags - inbuilt provision
>>>>> for tag-specific pages.
>>>>> >> Various themes to choose from, all cost-free.
>>>>> >> Pre-defined convention for best practices.
>>>>> >> Vast community support and one of the trending SSGs (according to
>>>>> stars on the repo in the past week: source)
>>>>> >>
>>>>> >> 11ty
>>>>> >>
>>>>> >> Written in JS, access to npm packages.
>>>>> >> No search functionality provided nor any documentation provided on
>>>>> how to implement it. Its docs site uses Duck Duck Go search.
>>>>> >> Versioning can be done by collections but not as intuitive as HUGO
>>>>> tags - no tag-specific pages.
>>>>> >> No provision for custom themes, need to start from scratch.
>>>>> Although many third-party themes are available. No documentation on using a
>>>>> custom theme as in HUGO.
>>>>> >> Flexible in terms of conventions.
>>>>> >> Good community support.
>>>>> >>
>>>>> >> Docusaurus
>>>>> >>
>>>>> >> Written in JS, access to npm packages.
>>>>> >> In-built search functionality powered by Algolia.
>>>>> >> In-built versioning functionality.
>>>>> >> Only one theme available needs to be customized to change. Uses
>>>>> React.
>>>>> >> Rigid conventions. Uses React components to render and therefore
>>>>> can not modify much in its default way of rendering.
>>>>> >>
>>>>> >> Absence of page-level variables, and therefore would cause
>>>>> difficulties when the SSG metadata is not allowed in the MD files. Not
>>>>> suited for our use case.
>>>>> >>
>>>>> >> Good community support, backed by Facebook.
>>>>> >>
>>>>> >> Clearly, we can't use Docusaurus. I took a look at Hexo and it had
>>>>> similar problems and has weak documentation. Similar goes for Docsify too.
>>>>> It doesn't have variables and weak templating and I also found its
>>>>> documentation less friendly. It can't be used for our requirements.
>>>>> >>
>>>>> >> This again puts me in favor of HUGO.
>>>>> >>
>>>>> >> Do you have any other suggestions?
>>>>> >>
>>>>> >>
>>>>> >> Thanks for the research, feel free to look at others or other
>>>>> setups that may inspire implementation.
>>>>> >>
>>>>> >>
>>>>> >>>
>>>>> >>> I’ve left some more comments below.
>>>>> >>>
>>>>> >>> Thanks
>>>>> >>> Justin
>>>>> >>>
>>>>> >>> On Mar 8, 2020, at 1:16 AM, Yash Jipkate <yashjipkate at gmail.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> Hi Justin,
>>>>> >>>
>>>>> >>> I just got a reply from the 11ty team on the issue that I opened.
>>>>> 11ty has directory specific data files that can be used to define config to
>>>>> be shared to all the lower levels. The major downside of this is that the
>>>>> directory specific data file needs to be placed in the directory itself.
>>>>> Therefore, the data file will be directly in between the content files.
>>>>> >>>
>>>>> >>>
>>>>> >>> You say that the data file can define configuration that can be
>>>>> shared by lower levels. So you could have two levels of directories, one
>>>>> that contains the data file and a directory of all the docs. In that way
>>>>> you wouldn’t haven’t worry about mixing them together. But I’d have to see
>>>>> how this looks in a more concrete example.
>>>>> >>
>>>>> >>
>>>>> >> If I am getting it the right way, you are planning to have a single
>>>>> data file. Yes, that would then nullify the point since we won't be
>>>>> concerned with the mixing of just one data file. But in case of multiple
>>>>> data files, say we want to customize some folders that should be different
>>>>> from the other folders at the same level, then we would need different data
>>>>> files in both the folders, and that's the kind of mixing that I'm concerned
>>>>> with.
>>>>> >>
>>>>> >>
>>>>> >> I was suggesting something like
>>>>> >>
>>>>> >> - Tutorials/
>>>>> >> - data file
>>>>> >> - pages/
>>>>> >> - tutorial_example.md
>>>>> >> - API
>>>>> >> - data file
>>>>> >> - pages/
>>>>> >> - framework_api.md
>>>>> >>
>>>>> >> I’m not exactly sure what our needs would be in terms of
>>>>> configuration in these files, do we actually need one per document file,
>>>>> one per section, or just one overall. The above example assumes one per
>>>>> section.
>>>>> >
>>>>> >
>>>>> > Currently, we would need one configuration file per version. There
>>>>> are three things that would be different on each page - the title, GitHub
>>>>> edit link, and the version. This information would be normally provided via
>>>>> the front-matter of the page but in our case, this can be provided in a
>>>>> data file (or a shared template). The title and the GitHub link can be
>>>>> generated from the name of the file using a variable but the version needs
>>>>> to be provided as a tag. So this tag would need to be in the data file (or
>>>>> the shared template) of the directory that houses it. This means that there
>>>>> would be one data file per version and a global data file.
>>>>> >
>>>>> > The structure you laid out also does some mixing. The data file is
>>>>> inside the contents folder which would contain all the MD files. In HUGO
>>>>> this data file is totally outside of the contents folder. While this
>>>>> doesn't have any significant performance effects, it is mainly a
>>>>> convention-related issue. Because we would then be cloning the repo
>>>>> 'tagwise' inside these folders. So do we want the cloned part directly in
>>>>> between the SSG data files or do we want these two in separate folders, is
>>>>> a matter of convention and developer ease. I would personally prefer having
>>>>> these two separate. What is your take on this?
>>>>> >
>>>>> >
>>>>> > I guess this all depends on what the directory structure looks like
>>>>> in the SSG. It seems we might have directories for each tag/version and the
>>>>> file could be in there, or possibly we might b able to source the
>>>>> tag/version name from the path that the files are in.
>>>>>
>>>>>
>>>>> I favor the tag-wise directory structure since that would help in
>>>>> setting archetypes. I am not sure what do you mean by sourcing the tag
>>>>> name, we would still need to clone tag-wise to detect the tag/version
>>>>> name from the path, right? In that case, archetypes would do the
>>>>> trick.
>>>>>
>>>>
>>>> Maybe we’re talking about different things, I’ll wait to see what it
>>>> looks like in your proposal.
>>>>
>>>> >
>>>>> >
>>>>> > Now that you mention the GitHub edit link, I don’t think tags are
>>>>> going to work. The tag is frozen, so to speak. We may need to use branches
>>>>> instead, or a combination of branches and tags. I don’t think it will
>>>>> change your workflow much, or at all, though.
>>>>>
>>>>>
>>>>> Yes, the tags are frozen, thanks for pointing that out. However, the
>>>>> tags and branches are inconsistent. The branches are 1.9.x, 2.x.x, and
>>>>> master, whereas the tags are v2.0.0 and v1.5.0. Also, would it be
>>>>> sensible to have a GitHub edit link for older versions? I saw the
>>>>> documentation for Angular and React, and both of them have their
>>>>> documentation for older versions snapshotted and do not edit them. The
>>>>> edit on GitHub button on the older versions' docs are either dead or
>>>>> point to the current branch of the docs. Therefore, I suggest that we
>>>>> follow the tag-wise classification since that is the most widely
>>>>> accepted format. What do you think?
>>>>>
>>>>
>>>> That’s an options, although I’d prefer not to have the link than to
>>>> have a dead one. It would be nice to be able to change the documentation
>>>> after the fact in case there was an error, typo, or missing information.
>>>> I’m not sure how likely that is though.
>>>>
>>>> >
>>>>> >
>>>>> >>
>>>>> >>>
>>>>> >>> According to my plan, the content repo was to be cloned in the SSG
>>>>> repo, so if 11ty is to be used then after the cloning we would need to
>>>>> further copy the directory specific data files into respective folders to
>>>>> make them useful.
>>>>> >>>
>>>>> >>>
>>>>> >>> I guess this should be counted as a downside for 11ty since this
>>>>> extra copying operation would require an extra script to maintain and would
>>>>> cause a closer coupling.
>>>>> >>>
>>>>> >>>
>>>>> >>> You’d still need some sort of script to do the cloning, so not
>>>>> sure how much extra work it would be. Maybe I’m forgetting or missing
>>>>> something with how you were planning to do the clone.
>>>>> >>
>>>>> >>
>>>>> >> Ideally, there should be one script for one functionality, so
>>>>> therefore I was thinking of a different script. And moreover, by a script,
>>>>> I meant by the code - maintaining it would be an additional task
>>>>> irrespective of whether it is in a separate file or not. Since it couples
>>>>> the two repos very closely, the maintenance can be frequent. And yes,
>>>>> cloning would be done through a script.
>>>>> >>
>>>>> >>
>>>>> >> I think we talked about possibly having a config file in the
>>>>> document repo that defined the parts or organization. It could also be that
>>>>> they are organized in a specific way, example directories to categorize the
>>>>> contents. We’d just need to know how to parse or place these directories
>>>>> and not each individual file. In this case there is a contract on what the
>>>>> incoming directory structure is, or instructions on how to move from one to
>>>>> another. Something to think about.
>>>>> >
>>>>> >
>>>>> > I thought that we wanted to separate all SSG related data from the
>>>>> content repo - that would include the config file as well. And yes, we just
>>>>> need to decide on the directory structure and the content would be placed
>>>>> accordingly and the SSG can then render the content.
>>>>> >
>>>>> >
>>>>> > The config file I meant here is something that would define the
>>>>> structure of the content repo. The SSG repo would use this to know what
>>>>> parts are what. It wouldn’t be something particular to a specific SSG,
>>>>> there would need to be something in the SSG repo that translated it to it’s
>>>>> own information. But having a consistent directory structure could possibly
>>>>> be used in place of such a file.
>>>>>
>>>>>
>>>>> The structure of the content repo would be determined by the way the
>>>>> data files (archetypes) are stored. The directory hierarchy of the doc
>>>>> files would be the same as I pointed out, and the other files would be
>>>>> re-organized. I don't think there is a feature such as a config to
>>>>> determine the directory structure. The directory structure needs to be
>>>>> consistent with the config of the SSG because the theme and the
>>>>> archetypes will be valid on a content structure that is similar to
>>>>> itself. Please correct me if I got you wrong.
>>>>>
>>>>
>>>> What I mean is that you’d have some document in the content repo that
>>>> identifies it’s structure. The SSG repo, on importing in the content would
>>>> use this to place the files in the locations that the SSG is
>>>> expecting/needs them to be.
>>>>
>>>
>>> The SSG does not identify the structure of the contents, it would
>>> validate the structure against the structure it is provided by the
>>> combination of templates and archetypes. If it finds a different structure,
>>> then it won't apply the templates. We can think of it as CSS selectors. Say
>>> we have two CSS selectors as '.body .div .p'  and '.body .div' and suppose
>>> we have a <h1> inside <body><div> then we don't have a CSS selector for
>>> '.body .div .h1'  so it won't give any errors but it would simply apply
>>> '.body .div' properties to it. And so the directory structure would need to
>>> be consistent between the two repos.
>>>
>>>
>>> Thanks for the detailed explanation. I actually meant that you would
>>> have to create something as part of your import script that read in the
>>> config doc and placed the files and directories in the locations that are
>>> needed for the SSG.
>>>
>>
>> Ah, yes. The script would be configured to import the contents of the
>> repo so that the imported documents are placed in their expected locations.
>>
>>>
>>>
>>>>
>>>> >
>>>>> > The directory structure of the contents (src/documents) need not be
>>>>> changed except for the images directory which would be moved to the static/
>>>>> or as a page resource if it needs some processing (one more point where
>>>>> HUGO beats 11ty since 11ty doesn't have any image processing features).
>>>>> >
>>>>> > We want the documentation to be readable/previewable on GitHub. That
>>>>> means that the URLs (e.g. links between documents, images, etc) would need
>>>>> to work both on GitHub and in the SSG created site. This may involve some
>>>>> translation of these URLs. In the current site we do some of this
>>>>> translation for changing between .md and .html, for example.
>>>>>
>>>>>
>>>>> The images which don't need preprocessing (like resizing) can be
>>>>> served directly from the static directory by relative paths and
>>>>> through server URLs (docs). The relative path method doesn't give
>>>>> previews in GitHub, whereas the URL method should give since that
>>>>> doesn't have to do anything with the content management system of
>>>>> HUGO.
>>>>>
>>>>
>>>> I’m not sure what you mean here, or at least I’m not sure how this
>>>> addresses the issue of URLs working on both GitHub and the final site.
>>>>
>>>
>>> Actually, if you follow the relative path method (i.e. if the image is
>>> in static/images/image1.png then the relative path in HUGO would be
>>> /images/image1.png) it would work correctly when HUGO renders it in HTML
>>> but won't be available in GitHub preview. Whereas if you use the full URL
>>> (i.e. https://<root-url>/images/image1.png) then we can see the correct
>>> GitHub preview as well. The only condition is that the image needs to
>>> already hosted on the server so that it can be tested in local development
>>> because HUGO generates such URLs for all static files. Here I'm talking in
>>> the context of the syntax of displaying an image in Markdown i.e.
>>> ![alt-text](img-url/path).
>>>
>>>
>>> The relative paths to images should work on GitHub. You can see the “Creating
>>> a New Adjuster UI
>>> <https://github.com/fluid-project/infusion-docs/blob/master/src/documents/tutorial-prefsFramework/CreatingANewAdjusterUI.md>”
>>> markdown file from our repo as an example. The links between documents is a
>>> bit harder because png GitHub you have to reference “.md” files and on the
>>> site you’ll reference “.html” files. In our current site, you can see that
>>> we transform the URLs to be correct when generating the site.
>>>
>>> It’s preferable for the links in GitHub to be self referential so that
>>> if the website is down, or if you just clone the docs repo and use that
>>> locally, the links still work. Also, if you are creating new docs or
>>> modifying existing ones, you’ll be able to test that the URLs are working.
>>>
>>
>> This is an issue with HUGO that it doesn't render the images when
>> relative URLs are used. I have opened a ticket
>> <https://discourse.gohugo.io/t/how-to-render-image-in-github-markdown/23951/2> in
>> the support forum of HUGO. I also saw some previous
>> <https://discourse.gohugo.io/t/image-path/1721> tickets
>> <https://discourse.gohugo.io/t/is-there-a-way-to-control-markdown-images-in-hugo/6687/4>
>>  related to this topic. I got a reply from the team in which he gave me
>> a link to one of his projects
>> <https://github.com/bep/portable-hugo-links> where he achieved this. In
>> HUGO there is a feature where we can convert a page into a bundle (like in
>> the repo p1
>> <https://github.com/bep/portable-hugo-links/tree/master/blog/p1> is
>> converted to a bundle - by adding index.md) so the links would work both in
>> preview as well as the site.
>>
>> We will have to make all those pages which are having images into
>> bundles. This is done by having a directory with the name of the page and
>> an index.md and the images in that directory. The import script would take
>> the name of such MD files from the docs repo and make them into folder
>> names and then import the images required into that directory. One way to
>> conveniently carry this out would be to have these types of directories in
>> the contents repo itself. Say, there is currently a doc *blog.md *which
>> uses *img.png* stored in images/, we can re-organize this into a *blog* directory
>> with *index.md *and the *img.png* in it. This way it would be easier to
>> group the pages and their resources in one place and avoid unnecessary
>> scripting and heavy coupling which would be vulnerable to breakage.
>>
>>
>> I’m not sure if I’m not fully understanding the issue, but it doesn’t
>> seem to be a problem or require a complex solution. For example it seems
>> like images should work from an image directory under in the static
>> directory ( https://discourse.gohugo.io/t/image-path/1721/3 ). Another
>> way would be to use markdown render hooks
>> <https://gohugo.io/getting-started/configuration-markup/#markdown-render-hooks>.
>> Anyways, I wonder if we’re getting into too much specifics. It might be
>> better to think of the end goal, and then think of how to get there with a
>> few systems. Then you can compare the pros and cons. Perhaps this is what
>> you are doing here with Hugo. I’m just saying that we shouldn’t get too far
>> ahead with implementation details just yet.
>>
>
> Actually, in the post you referred, the way he mentioned would only
> display it in the rendered HTML. I have tried it for myself. The markdown
> render hook method can also be looked upon. This method makes use of page
> resources whereas the page bundle method renders the image just by
> referring the relative path. I will look at the pros and cons of both the
> methods and then decide on one.
>
>>
>>
>>>
>>>> >
>>>>> > The layout file in the layouts folder would be replaced by a
>>>>> template layout file that is provided by the SSG. In the case of HUGO, this
>>>>> can be achieved through themes, partials, and templates
>>>>> > The static folder would be placed in static/ in the project root.
>>>>> > I am not clear about what is the purpose of the ghpages-files
>>>>> directory. In the deploy section of the README, it says that we don't use
>>>>> GitHub pages to host. Then what is the use of this directory? Also, what
>>>>> service do we currently use to host the site?
>>>>> >
>>>>> > There is some legacy in that we had originally used ghpages to host
>>>>> the site, but moved to self hosting. We may move to a hosting service at
>>>>> some point (e.g. back to ghpages, netlify, etc.). We should investigate
>>>>> removing the ghpages-files directory.
>>>>> >
>>>>> >
>>>>> >>
>>>>> >>>
>>>>> >>>
>>>>> >>> I am still inclined to HUGO because of our use case. Lesser
>>>>> coupling, faster build times (since there are multiple steps like dispatch
>>>>> and cloning and that would add to the build time) and a file structure
>>>>> convention are some features that outperform 11ty. Some star features of
>>>>> 11ty like multiple templates are not required by us since we use only MD
>>>>> files.
>>>>> >>>
>>>>> >>> What do you think?
>>>>> >>>
>>>>> >>>
>>>>> >>> Addressing some of the comments/questions from earlier in the
>>>>> thread. Not sure what the issue about Hugo being written in Go. Could you
>>>>> explain and expand on that one more.
>>>>> >>
>>>>> >>
>>>>> >> Being built in Go means it is deprived of the amazing features of
>>>>> JS. Most importantly, the features of node and NPM which have many useful
>>>>> packages. This has been the main concern of many developers.
>>>>> >>>
>>>>> >>>
>>>>> >>> Regarding flexibility. That’s not necessarily a bad thing. If we
>>>>> maintain consistency in our use and follow best practices, I don’t think it
>>>>> should be a matter for us and could mean that we can tailor it to our own
>>>>> needs. If you know of a specific issue that 11ty’s flexibility is causing,
>>>>> or could cause, it would be good to discuss it more.
>>>>> >>
>>>>> >>
>>>>> >> If we are sure of maintaining best practices then this won't be
>>>>> much of a problem. Actually, this was the case of AngularJS - it didn't
>>>>> have a 'conventional' way of doing things and this resulted in a number of
>>>>> bad practices. The new Angular then removed this by introducing a less
>>>>> flexible framework. We can overcome this by setting up our own conventions
>>>>> that would eliminate any bad practices that might pop up.
>>>>> >>
>>>>> >>
>>>>> >> A contributing guide and documentation on usage, best practices,
>>>>> conventions and etc. should be included with the project.
>>>>> >
>>>>> >
>>>>> > Yes, that would be very important in deciding and cementing the
>>>>> conventions.
>>>>> >>
>>>>> >>
>>>>> >>>
>>>>> >>>
>>>>> >>> Thanks
>>>>> >>> Yash
>>>>> >>>
>>>>> >>> On Sat, Mar 7, 2020 at 11:59 PM Yash Jipkate <
>>>>> yashjipkate at gmail.com> wrote:
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> Hi Justin,
>>>>> >>>>
>>>>> >>>> I looked up 11ty more and found the following advantages over
>>>>> HUGO:
>>>>> >>>>
>>>>> >>>> 11ty (2017) is newer than HUGO (2013).
>>>>> >>>> 11ty is built using JavaScript whereas HUGO is built using Go. JS
>>>>> being a native web language won't ever lose support whereas Go being a
>>>>> third party might lose support.
>>>>> >>>> 11ty has more flexibility regarding file extensions. It works
>>>>> with formats other than MD as well.
>>>>> >>>> 11ty has a flexible file system. So we can build it right from
>>>>> the current file structure.
>>>>> >>>> I also liked the documentation of 11ty compared to the one by
>>>>> HUGO.
>>>>> >>>>
>>>>> >>>> But there is a major downside that since 11ty uses a flexible
>>>>> directory structure, every page needs to have a front matter that specifies
>>>>> the template it needs to use. HUGO being strict about directory structure
>>>>> automates this process and is useful when we want to separate the content
>>>>> from the front matter.
>>>>> >>>>
>>>>> >>>> I found this issue to fulfill our use case but it was closed with
>>>>> a note stating it was solved in a version but I couldn't find any
>>>>> documentation regarding it. Therefore I opened an 'education' type issue to
>>>>> get their response.
>>>>> >>>>
>>>>> >>>> If this issue persists, then we might not be able to use 11ty for
>>>>> our purpose.
>>>>> >>>>
>>>>> >>>> Thanks
>>>>> >>>> Yash
>>>>> >>>>
>>>>> >>>> On Sat, Mar 7, 2020 at 12:28 AM Yash Jipkate <
>>>>> yashjipkate at gmail.com> wrote:
>>>>> >>>>>
>>>>> >>>>> Hi Justin,
>>>>> >>>>>
>>>>> >>>>> Thanks for the reply. I have responded inline.
>>>>> >>>>>
>>>>> >>>>> Thanks.
>>>>> >>>>> Yash
>>>>> >>>>>
>>>>> >>>>> On Thu, 5 Mar 2020, 7:02 pm Justin Obara, <
>>>>> obara.justin at gmail.com> wrote:
>>>>> >>>>>>
>>>>> >>>>>> Hello Yash,
>>>>> >>>>>>
>>>>> >>>>>> Please see comments inline below.
>>>>> >>>>>>
>>>>> >>>>>> Thanks
>>>>> >>>>>> Justin
>>>>> >>>>>>
>>>>> >>>>>> On Mar 5, 2020, at 2:43 AM, Yash Jipkate <yashjipkate at gmail.com>
>>>>> wrote:
>>>>> >>>>>>
>>>>> >>>>>> Hi Justin,
>>>>> >>>>>>
>>>>> >>>>>> Just confirming whether you got my previous email. Is there
>>>>> something I should add or elaborate on?
>>>>> >>>>>>
>>>>> >>>>>> Thanks
>>>>> >>>>>> Yash
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>> On Tue, Mar 3, 2020 at 3:14 AM Yash Jipkate <
>>>>> yashjipkate at gmail.com> wrote:
>>>>> >>>>>>>
>>>>> >>>>>>> Hi Justin,
>>>>> >>>>>>>
>>>>> >>>>>>> I will try to mark the issues on JIRA since it should have
>>>>> only legitimate issues.
>>>>> >>>>>>> Also, I tried out the repository communication. I created a
>>>>> dispatcher repo and added a workflow to send a dispatch to another consumer
>>>>> repo created by me. It worked perfectly and the repo was consuming the
>>>>> event.
>>>>> >>>>>>
>>>>> >>>>>> How is the consumer repo affected by forks of the dispatcher
>>>>> repo. That is, if I fork your dispatcher repo and push to it, will it send
>>>>> a dispatch event to your consumer repo and trigger an action?
>>>>> >>>>>>
>>>>> >>>>>> It’s also worth investigating other methods that do not couple
>>>>> the repos together so closely.
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> No, the dispatch event does not work on forks. I forked the
>>>>> dispatcher repo here and pushed to the main branch. This failed to trigger
>>>>> the workflow in the main consumer repo (you can check here). Also forking
>>>>> the consumer repo won't have any downside since the dispatch event demands
>>>>> the name of the repo along with the owner so forks won't be affected.
>>>>> >>>>>
>>>>> >>>>> Another method I initially thought before discovering repo
>>>>> dispatches was to have a special server for the sole purpose of sending and
>>>>> receiving events that would trigger builds. This would allow us to have
>>>>> custom features not limited by those offered by GitHub API. The downside is
>>>>> that we would need to maintain an additional repo and would not be able to
>>>>> access the community help that exists for GitHub's API. Also since out
>>>>> needs are satisfied by the GitHub's API, we won't need any other custom
>>>>> features than the ones already present.
>>>>> >>>>>>>
>>>>> >>>>>>> I think the design would not undergo much change. I saw the
>>>>> official documentation page of HUGO and they use pretty much similar design
>>>>> - a top nav, a side nav, and the main content.
>>>>> >>>>>>>
>>>>> >>>>>>> The source code is open-sourced here. I looked at the code and
>>>>> saw that the menu bar items were hard-coded in a site-wide config file
>>>>> here. The layout for the menu bars are placed in partials/ of the theme
>>>>> that HUGO's site uses.
>>>>> >>>>>>> To maintain the design of the current site, we would have to
>>>>> make a custom theme of our own (similar to the theme used by HUGO docs).
>>>>> >>>>>>> The structure of the files would also need to be changed
>>>>> accordingly. The md files or the content files would be put under content/
>>>>> and assets under static/.
>>>>> >>>>>>>
>>>>> >>>>>>> The repo would be essentially HUGO-oriented, with all the
>>>>> folder structure conforming to the one required by HUGO. In case of
>>>>> switching to another SSG, we would need to follow the folder structure and
>>>>> the conventional best practices followed by that particular SSG. We would
>>>>> again need a restructuring, although not this massive. Also, things like
>>>>> menu bar items which would be in the root config of HUGO would also be
>>>>> needed to migrate since the new SSG might have a different approach.
>>>>> >>>>>>
>>>>> >>>>>> Regarding the folder structure, couldn’t we just copy/import
>>>>> the content to whichever location we wanted during that step of the
>>>>> workflow. Do we have to mirror it in the content repo?
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> Yes, that's exactly what I am proposing. I plan to re-organize
>>>>> the folder structure and not mirror the current content to the new
>>>>> structure.
>>>>> >>>>>>>
>>>>> >>>>>>> Splitting the docs and the HUGO code would deprive of the many
>>>>> useful and core features of the tech. The front-matter or the meta-data per
>>>>> page is of great use and can be used to greatly customize and control the
>>>>> pages. Stripping HUGO of such important features could become a problem in
>>>>> the future or even during this project. For example, the GitHub link to
>>>>> edit the page is different on every page and can be stored in front-matter.
>>>>> Also, if we wanted to add an 'author' or 'last updated' information to the
>>>>> page, It would again be a front-matter thing.
>>>>> >>>>>>
>>>>> >>>>>> Can this information be automatically generated on import of
>>>>> the content?
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> We can have a common front matter template for all files in a
>>>>> directory by the archetype feature of HUGO.
>>>>> >>>>>>>
>>>>> >>>>>>> Also, in case of switching SSG, the main part i.e. the MD doc
>>>>> files would be in the same hierarchy of contents. The only change that
>>>>> mostly happens in the names of the directories and some best practice
>>>>> conventions. Therefore, in my opinion, we should not split the codebase
>>>>> since it would be almost equal work switching in both cases but the
>>>>> one-repo approach gives many more additional features, and this advantage
>>>>> would be in other SSGs too.
>>>>> >>>>>>> I took a look at some other SSGs like Jekyll and 11ty. Most of
>>>>> my findings were the same as those by Sachin. One of the main drawbacks of
>>>>> Jekyll is build time increases exponentially with increase in repo size.
>>>>> 11ty has somewhat less community support.
>>>>> >>>>>>>
>>>>> >>>>>>> For choosing an SSG, the choice should be between Jekyll and
>>>>> HUGO. Jekyll has a somewhat rigid structure whereas HUGO is flexible. I
>>>>> would recommend HUGO for the task.
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>> Could you explain more about your recommendations, in
>>>>> particular against 11ty. Also, did you look at any others besides these
>>>>> three?
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> I looked at Gatsby and Gridsome - the two other main SSGs - but
>>>>> they are framework dependent i.e. on React and Vue respectively and can be
>>>>> difficult for those who haven't worked in that area. SSGs like 11ty and
>>>>> HUGO are easy to learn and setup.
>>>>> >>>>>
>>>>> >>>>> Right now, 11ty has lesser community support than HUGO. One pro
>>>>> of using 11ty is that it can be configured to run in the current directory
>>>>> structure. Although this can be tempting at first, in my personal
>>>>> experience, too much flexibility causes a lack of convention and leads to
>>>>> bad practices. This has been the case of AngularJS which being too flexible
>>>>> gave way to randomness in conventions. One other advantage is that it can
>>>>> handle more than just md files, but since all our documentation is in md
>>>>> format, this isn't of much concern.
>>>>> >>>>>
>>>>> >>>>> Therefore I would recommend HUGO. However, I will try to
>>>>> research more on this topic and will update you if I find HUGO outperformed
>>>>> by another SSG.
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>> What are your opinions on this?
>>>>> >>>>>>>
>>>>> >>>>>>> On Mon, Mar 2, 2020 at 6:27 PM Justin Obara <
>>>>> obara.justin at gmail.com> wrote:
>>>>> >>>>>>>>
>>>>> >>>>>>>> Hi Yash,
>>>>> >>>>>>>>
>>>>> >>>>>>>> It isn’t required to work on those issues. However, feel free
>>>>> to triage them and leave comments as necessary (e.g. if they are no longer
>>>>> applicable and should be closed).
>>>>> >>>>>>>>
>>>>> >>>>>>>> Other things you could look at in preparation for your
>>>>> proposal would be:
>>>>> >>>>>>>>
>>>>> >>>>>>>> The cross repo event communication you mentioned
>>>>> >>>>>>>> The current structure, design, and etc.. how that might be
>>>>> affected by splitting things up
>>>>> >>>>>>>> Other static site generators, pros/cons for using which ones
>>>>> >>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>> Also, regarding your comments about HUGO, if I’m
>>>>> understanding things correctly, HUGO’s speed benefits are at
>>>>> build/generation time, not necessarily when viewing the site.
>>>>> >>>>>>>>
>>>>> >>>>>>>> Feel free to ask other questions you may have.
>>>>> >>>>>>>>
>>>>> >>>>>>>> Thanks
>>>>> >>>>>>>> Justin
>>>>> >>>>>>>>
>>>>> >>>>>>>> On Mar 1, 2020, at 1:21 AM, Yash Jipkate <
>>>>> yashjipkate at gmail.com> wrote:
>>>>> >>>>>>>>
>>>>> >>>>>>>> Also, the issues in the JIRA tracker you shared are very old
>>>>> and some don't seem to apply now. Should I be working on them?
>>>>> >>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>> On Sat, Feb 29, 2020 at 5:32 PM Yash Jipkate <
>>>>> yashjipkate at gmail.com> wrote:
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> Hi Justin,
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> Apologies for late reply, was busy with my exams, but they
>>>>> are gone for good now. I have addressed your comments below.
>>>>> >>>>>>>>>
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> On Wed, Feb 26, 2020 at 8:31 PM Justin Obara <
>>>>> obara.justin at gmail.com> wrote:
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> On Feb 25, 2020, at 3:36 PM, Yash Jipkate <
>>>>> yashjipkate at gmail.com> wrote:
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Hi Justin,
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Thanks for the reply. Apologies for the late response from
>>>>> my side as I am in the middle of my exams. But I'll try to address as much
>>>>> as I can. I have left them inline.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> On Tue, Feb 25, 2020 at 6:58 AM Justin Obara <
>>>>> obara.justin at gmail.com> wrote:
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Hi Yash,
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Thanks for your interest in this project. I’ve left some
>>>>> comments inline below.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Thanks
>>>>> >>>>>>>>>>> Justin
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> On Feb 24, 2020, at 4:29 PM, Yash Jipkate <
>>>>> yashjipkate at gmail.com> wrote:
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Hi everyone,
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> I am Yash, and I need some discussion regarding the
>>>>> project "Refactor and Automating Infusion Documentation" and wanted to get
>>>>> your opinions on it.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> The HUGO code would be in a different repository; this
>>>>> would mean that the current repo would have to be cleaned of any rendering
>>>>> code, just .md and static files would remain. There is a way to clone
>>>>> another repo into a repo with the help of a script in the CI job.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Yes, ideally the content would be separate so that the
>>>>> Static Site Generator could be changed if needed, without the need to
>>>>> modify any of the content. Setting up a CI job, e.g. using GitHub Actions,
>>>>> could be one possible means of retrieving the content. Although this would
>>>>> also need to be easily testable for development so would likely involve
>>>>> some build task that could be run locally as well.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> By testable, do you mean testing the code changes in the
>>>>> HUGO repo or the changes in the docs repo? Does the docs repo need testing?
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> I’d say both. For example if you make some docs changes,
>>>>> you’ll want to make sure that it renders correctly, and links to other
>>>>> pages are functioning. That might involve running an instance of the Static
>>>>> Site Generator locally. Actually thinking through this process would be
>>>>> helpful too. It may affect how we make other decisions related to this
>>>>> project.
>>>>> >>>>>>>>>
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> So I was thinking that we could have a script for local
>>>>> testing of the docs repo - something like `bash run test.sh` - which would
>>>>> use the config files of HUGO to run a local instance of docs. We can have
>>>>> those config files in a tests/ folder. HUGO can be configured to look for
>>>>> necessary files other than at the root level. We can pull the required
>>>>> files directly from the remote server rendering repo and delete them or add
>>>>> them to .gitignore to avoid getting those in the repo.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> The CI should trigger whenever there is a push to main
>>>>> docs repo; this can be achieved by broadcasting a repository dispatch event
>>>>> from the main docs repo.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Will another GitHub repo be able to consume the
>>>>> “repository dispatch event”?
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Yes, the dispatch event is a POST request sent to the repo
>>>>> we are targeting.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Could you like to the docs for the dispatch event both for
>>>>> sending and consuming it?
>>>>> >>>>>>>>>
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> You can find them here and here.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> The cloning of the repo can be done tag-wise, i.e.,
>>>>> instead of cloning the whole repo, cloning just a specific tag(s) would be
>>>>> done looped over all the available tags.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> That could work. Does that actually save complexity and
>>>>> time over checking out the whole repo and locally iterating over tags?
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> I guess it would take slightly more time than cloning the
>>>>> whole repo, but HUGO doesn't have git variables that could extract tags
>>>>> from it, that's why I came up with this solution.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> There are some libraries for indexing content and
>>>>> implementing the search functionality like hugo-lunr
>>>>> >>>>>>>>>>> The front matter - since it is required to not include it
>>>>> in the files of the main docs repo - can be made as layouts. The only
>>>>> needed front matter seems to be the title of the page and the GitHub link -
>>>>> both of which can be determined with the help of FIle Variables in HUGO.
>>>>> >>>>>>>>>>> The file structure would result as follows: All the .md
>>>>> documentation files would be having the same organization with their tags
>>>>> at the topmost level. In other words, the file structure for the .md files
>>>>> would be content -> <tag> -> <files-in-their =-original-structure>. The
>>>>> static files would be placed in static/ at the same level as 'content' as
>>>>> required by HUGO.
>>>>> >>>>>>>>>>> After cloning a tag, its contents would be copied to
>>>>> relevant directories, and then the clone would be deleted, and the process
>>>>> would be repeated for each tag, thus watching changes in each tag.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> These are some of my findings. What are your opinions?
>>>>> Should this be the way to do it? Or am I missing something that needs to be
>>>>> addressed?
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> I don’t know for sure if this will work or is the best
>>>>> solution, but it looks like a good starting point to continue to research
>>>>> and test from. You can also look into other static site generators if there
>>>>> are others that may satisfy the requirements better.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Okay, I'll take a look at some other site generators as
>>>>> well.
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> I think HUGO would be a good fit because of its extreme
>>>>> speed. In my opinion, a docs site should be as fast as possible since
>>>>> developers come there mostly when they are searching for something and no
>>>>> one wants a preloader to take most of their time. What do you think?
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> It would be great if I could get some insight into this.
>>>>> Also, it would be of great help if I get some guidance on how to start
>>>>> since the current docs repo has no standing issues on the tracker.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> You can find more issues in the JIRA issue tracker:
>>>>> https://issues.fluidproject.org/browse/FLUID-6160?jql=project%20%3D%20FLUID%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20Website
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Oh, wasn't aware of this tracker, thanks for pointing out.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> But you should also start by making sure you can get the
>>>>> current site up and running locally.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Do you mean using docpad? If yes, then I have already done
>>>>> that.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Yes that’s what I meant.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Thanks and Regards,
>>>>> >>>>>>>>>>> Yash Jipkate
>>>>> >>>>>>>>>>> Sophomore Undergraduate,
>>>>> >>>>>>>>>>> IIT(BHU) Varanasi
>>>>> >>>>>>>>>>> India
>>>>> >>>>>>>>>>>
>>>>> >>> <image.gif>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> _______________________________________________________
>>>>> >>>>>>>>>>> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
>>>>> >>>>>>>>>>> To unsubscribe, change settings or access archives,
>>>>> >>>>>>>>>>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Thanks and Regards,
>>>>> >>>>>>>>>> Yash Jipkate
>>>>> >>>>>>>>>> Sophomore Undergraduate,
>>>>> >>>>>>>>>> IIT(BHU) Varanasi
>>>>> >>>>>>>>>> India
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> Thanks and Regards,
>>>>> >>>>>>>>> Yash Jipkate
>>>>> >>>>>>>>> Sophomore Undergraduate,
>>>>> >>>>>>>>> IIT(BHU) Varanasi
>>>>> >>>>>>>>> India
>>>>> >>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>> Thanks and Regards,
>>>>> >>>>>>>> Yash Jipkate
>>>>> >>>>>>>> Sophomore Undergraduate,
>>>>> >>>>>>>> IIT(BHU) Varanasi
>>>>> >>>>>>>> India
>>>>> >>>
>>>>> >>> <image.gif>
>>>>> >>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>> Thanks and Regards,
>>>>> >>>>>>> Yash Jipkate
>>>>> >>>>>>> Sophomore Undergraduate,
>>>>> >>>>>>> IIT(BHU) Varanasi
>>>>> >>>>>>> India
>>>>> >>>
>>>>> >>> <image.gif>
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>> <image.gif>
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>
>>>>> >>> <image.gif>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>
>>>>> >>> <image.gif>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> --
>>>>> >>> Thanks and Regards,
>>>>> >>> Yash Jipkate
>>>>> >>> Sophomore Undergraduate,
>>>>> >>> IIT(BHU) Varanasi
>>>>> >>> India
>>>>> >>>
>>>>> >>> <image.gif>
>>>>> >>>
>>>>> >>>
>>>>> >> <image.gif>
>>>>> >>>
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Thanks and Regards,
>>>>> >> Yash Jipkate
>>>>> >> Sophomore Undergraduate,
>>>>> >> IIT(BHU) Varanasi
>>>>> >> India
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Thanks and Regards,
>>>>> > Yash Jipkate
>>>>> > Sophomore Undergraduate,
>>>>> > IIT(BHU) Varanasi
>>>>> > India
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>> --
>>>>> Thanks and Regards,
>>>>> Yash Jipkate
>>>>> Sophomore Undergraduate,
>>>>> IIT(BHU) Varanasi
>>>>> India
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks and Regards,
>>>> Yash Jipkate
>>>> Sophomore Undergraduate,
>>>> IIT(BHU) Varanasi
>>>> India
>>>>
>>>> <image.gif>
>>>
>>>
>>>>
>>>
>>> --
>>> Thanks and Regards,
>>> Yash Jipkate
>>> Sophomore Undergraduate,
>>> IIT(BHU) Varanasi
>>> India
>>>
>>>
>>>
>>
>> --
>> Thanks and Regards,
>> Yash Jipkate
>> Sophomore Undergraduate,
>> IIT(BHU) Varanasi
>> India
>>
>>
>>
>
> --
> Thanks and Regards,
> Yash Jipkate
> Sophomore Undergraduate,
> IIT(BHU) Varanasi
> India
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20200316/cad1b5d5/attachment.html>


More information about the fluid-work mailing list