Github shared repo versus fork and pull / other Jude matters

68 views
Skip to first unread message

Eric

unread,
Apr 11, 2012, 12:23:28 AM4/11/12
to Julia MVC Framework
Do we want to do this at the beginning using a shared repo that we all
push too, or do fork/pull? Either's fine with me, but I'm concerned
that as we first start out and are writing a lot of code, all the pull
requests are going to create unneeded work for Nicholas. I agree we
should definitely move to that approach once we've got a working beta,
but it might be easier in the beginning for us all to have write
access to a central repo and just push our changes there. But I can
work with either approach.

Also, in terms of what we model Jude after, I'm good with Sinatra.
However, it's critical to remember that probably even at that first
commit, the majority of the framework code lived in Rack. And when
you look at the modern Rack, you begin to see what all we have to do:
https://github.com/rack/rack/tree/master/lib/rack

Now, don't despair when you see all that code. A lot of what you see
there is already done for Julia -- we have a web server and http
parser, and many of the various utilities used in Rack. And clearly
we don't need to be as complex at the beginning as the interface
that's the foundation of Sinatra, Rails, etc. But looking at Rack
gives you an idea of some of the functionalities we'll need to
create. If you're open to checking out some Python, you might also
want to take a look at Werkzeug -- the counterpart to Rack in the
Python world (along with another package called webob). You can find
werkzeug here: https://github.com/mitsuhiko/werkzeug

As we make this foundation for Jude, I think we should aim to make it
as decoupled as possible from the rest of the framework, so that if
someone comes along next year and wants to build a massive, Rails-type
framework for Julia, they won't have to extricate all the routing,
request/response wrappers, exception handling, parsers, etc. from the
rest of the framework (or do it themselves).

But all this is my opinion and I'm open to disagreement. What do you
all think?

Finally, I think it would be smart for us to create a basic project
page, maybe using Github's new templates. So I might try to throw
that together in the next day or two as well, unless someone else is
already working on it. And unless someone has already started the
request/response wrappers, I'll go ahead and start working on those.

Eric

Nicholas Klick

unread,
Apr 11, 2012, 2:04:31 AM4/11/12
to julia-mvc...@googlegroups.com
Thanks for this.

Couple things:

Maybe just clone and push directly against the main repo for now. Go ahead and just pull/push from https://k...@github.com/knf/jude.git.  Since everything is new and there are a lot of moving parts there is no need for managing pull requests till later etc.

I agree Sinatra relied heavily on Rack.

I agree with decoupling. My approach with both the testing framework and templating system was to make them separate packages that jude can load etc.

I think creating a basic github project page should wait ;) till maybe we have some code written. No need to advertise this yet. But feel free to disagree.

Now time for sleep :)

Eric

unread,
Apr 11, 2012, 9:28:39 AM4/11/12
to Julia MVC Framework
> Maybe just clone and push directly against the main repo for now. Go ahead
> and just pull/push from https://...@github.com/knf/jude.git.  Since
> everything is new and there are a lot of moving parts there is no need for
> managing pull requests till later etc.

Agreed. Will do.

>
> I agree with decoupling. My approach with both the testing framework and
> templating system was to make them separate packages that jude can load etc.

Great. Looking forward to seeing what you've done whenever you put it
up.

>
> I think creating a basic github project page should wait ;) till maybe we
> have some code written. No need to advertise this yet. But feel free to
> disagree.

I think you're right here. Let's wait until it's a little further
along.

Thanks for your suggestions.

Eric
Reply all
Reply to author
Forward
0 new messages