Skip to content
This repository has been archived by the owner on Jan 10, 2022. It is now read-only.

reasons to use calipso's respository as basis for my own site (vs. a fresh repo that isn't a direct "descendant")? #229

Open
laurelnaiad opened this issue Sep 28, 2013 · 14 comments

Comments

@laurelnaiad
Copy link
Contributor

So I'm getting started building my own site with calipso. I'm assuming I'll be doing quite a few patches to calipso itself along the way....

Am I going to experience pain and agony if I just develop the site in my clone of the calipso repository instead of doing calipso site /path/to/mysite?

I can already feel the pain of creating a separate site. If I develop directly in the calipso source, are there any gotchas when it comes time to deploying to, say, heroku?

I haven't really grokked the whole process of doing the deployment yet -- how best to deal with multiple databases and configurations and such, but it seems to me that the lesser of two evils, given that I'll probably be patching calipso while I go, is to just run from its source. Does this make sense?

How is everyone else handling this?

@laurelnaiad
Copy link
Contributor Author

short followup -- it would be awesome if calipso could be configured as an npm dependency of my app instead of my app living in calipso... I think that would make my brain hurt less ;)

@richtera
Copy link
Collaborator

If you deploy the git clone it works fine. This is how I deploy to
calip.so. The only thing is that some deployment methods like to take over
the package.json file. So you might need some helper scripts to make sure
you don't include the changed file in pull requests. But otherwise if you
add an environment variable called MONGO_ URI to your deployment pointing
to the database then calipso will store all configs in the database instead
and updating your site won't erase the config. If you have shell access and
you can manually manage the conf json file then that's possible as well of
course. Calip.so is using nodejitsu but I have played around with heroku as
well. Unless you have shell access the calipso command line is not easy to
use for you.
Thanks
Andy

Sent via the internets

On Sep 27, 2013, at 8:58 PM, Stu Salsbury notifications@github.com wrote:

So I'm getting started building my own site with calipso. I'm assuming I'll
be doing quite a few patches to calipso itself along the way....

Am I going to experience pain and agony if I just develop the site in my
clone of the calipso repository instead of doing calipso site
/path/to/mysite?

I can already feel the pain of creating a separate site. If I develop
directly in the calipso source, are there any gotchas when it comes time to
deploying to, say, heroku?

I haven't really grokked the whole process of doing the deployment yet --
how best to deal with multiple databases and configurations and such, but
it seems to me that the lesser of two evils, given that I'll probably be
patching calipso while I go, is to just run from its source. Does this make
sense?

How is everyone else handling this?


Reply to this email directly or view it on
GitHubhttps://github.com//issues/229
.

@richtera
Copy link
Collaborator

That's a good idea, but not currently implemented. Your code can site in
git clones inside of community inside of modules or themes. That's how I
connect external stuff and manager the repos.
Andy

Sent via the internets

On Sep 27, 2013, at 9:00 PM, Stu Salsbury notifications@github.com wrote:

short followup -- it would be awesome if calipso could be configured as an
npm dependency of my app instead of my app living in calipso... I think
that would make my brain hurt less ;)


Reply to this email directly or view it on
GitHubhttps://github.com//issues/229#issuecomment-25287022
.

@laurelnaiad
Copy link
Contributor Author

Cool -- thanks.

@laurelnaiad
Copy link
Contributor Author

@richtera do you use git submodules for your modules and themes?

@richtera
Copy link
Collaborator

No I don't. It's a good solution but it gets in the way of pull requests. I
manually check then out and then work in each. Maybe there is a better way
but I have not thought if one.

Sent from my iPhone

On Sep 29, 2013, at 11:43 AM, Stu Salsbury notifications@github.com wrote:

@richtera https://github.com/richtera do you use git submodules for your
modules and themes?


Reply to this email directly or view it on
GitHubhttps://github.com//issues/229#issuecomment-25322499
.

@richtera
Copy link
Collaborator

Note also that both modules and themes allow subfolders for that reason. So
you can have a site repo in each for example containing multiple modules or
themes.
Andy

Sent from my iPhone

On Sep 29, 2013, at 11:43 AM, Stu Salsbury notifications@github.com wrote:

@richtera https://github.com/richtera do you use git submodules for your
modules and themes?


Reply to this email directly or view it on
GitHubhttps://github.com//issues/229#issuecomment-25322499
.

@laurelnaiad
Copy link
Contributor Author

Thanks. I guess what you're saying is to use .gitignore as its set up to ignore the community directories so that they don't squeak into calipso, and set up git repositories in them for non-core stuff?

@laurelnaiad laurelnaiad reopened this Sep 29, 2013
@SocalNick
Copy link

Along these lines, if I install using the calipso site command, is there a prescribed .gitignore I should use when I commit my site to a git repo? I'm obviously going to ignore node_modules and the conf directory. What else shouldn't I commit?

@richtera
Copy link
Collaborator

I would start out with the .gitignore inside of the calipso repo.
Andy

Sent from my iPhone

On Dec 28, 2013, at 12:17 AM, Nicholas Calugar notifications@github.com
wrote:

Along these lines, if I install using the calipso site command, is there a
prescribed .gitignore I should use when I commit my site to a git repo? I'm
obviously going to ignore node_modules and the conf directory. What else
shouldn't I commit?


Reply to this email directly or view it on
GitHubhttps://github.com//issues/229#issuecomment-31290744
.

@richtera
Copy link
Collaborator

I am refactoring calipso to live inside of a module in each site rather than taking over the site.

@laurelnaiad laurelnaiad changed the title reasons not to use calipso repository for my own site? reasons to use calipso's respository as basis for my own site (vs. a fresh repo that isn't a direct "descendant")? May 25, 2014
@laurelnaiad
Copy link
Contributor Author

@richtera thanks for the update. I've not been doing anything with my project, but when I saw this it occurred to me that the title of this issue might be misleading, so I edited it. :) Please feel free to close it if you'd like. I hope your refactoring works out!

@richtera
Copy link
Collaborator

Yea I got the refactor to work. I am waiting to push it out to the main site since that's been a little flaky. How you're doing well. I remember you said you stopped using calipso. I have been too busy to pick it back up as well. Have a great day.
Andy

On May 25, 2014, at 3:31 PM, Stu Salsbury notifications@github.com wrote:

@richtera thanks for the update. I've not been doing anything with my project, but when I saw this it occurred to me that the title of this issue might be misleading, so I edited it. :) Please feel free to close it if you'd like. I hope your refactoring works out!


Reply to this email directly or view it on GitHub.

@richtera
Copy link
Collaborator

That was meant to say "Hope you're doing well."

On May 25, 2014, at 3:33 PM, Andreas Richter andy@richteralsi.com wrote:

Yea I got the refactor to work. I am waiting to push it out to the main site since that's been a little flaky. How you're doing well. I remember you said you stopped using calipso. I have been too busy to pick it back up as well. Have a great day.
Andy

On May 25, 2014, at 3:31 PM, Stu Salsbury notifications@github.com wrote:

@richtera thanks for the update. I've not been doing anything with my project, but when I saw this it occurred to me that the title of this issue might be misleading, so I edited it. :) Please feel free to close it if you'd like. I hope your refactoring works out!


Reply to this email directly or view it on GitHub.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants