Installing it on my ubuntu machine

[benny daon]

Hi guys,

In my quest to develop a Q&A site for the coming local election I've decided to try and use parts of the code from your project. here's how it went:

- names are confusing: is it open-budget or omuni-budget? depend if you look at rtd or github

- Installation

-- I had to use sudo for "npm install volo" 

-- I don't like the part about changing the hosts file. if every projects asked me to do it my hosts would look like shit

-- had to run 'volo add -noprompt' 3 times to get it to work

-- the quickstart doesn't include running the test

-- the tests fail

-- the local server doesn't work

I left it aside and copied the entities app to a separate repository so I can make it reusable - use it also for the Q&A. It went pretty good - the repo is here - https://github.com/daonb/django-entities, please use it instead of the entities you now have and we can keep improving it together.

Benny

http://yeda.us/daonb

[Paul Walsh]

Hey,

On Wednesday, 3 July 2013 17:34:45 UTC+3, daonb wrote:

Hi guys,

In my quest to develop a Q&A site for the coming local election I've decided to try and use parts of the code from your project. here's how it went:

- names are confusing: is it open-budget or omuni-budget? depend if you look at rtd or github

point taken.

 

- Installation

-- I had to use sudo for "npm install volo"

We wanted to avoid walking people through setting up OS, for reasons like this. Whether you use sudo or not is entirely dependent on how you installed node, and we can't see everyone's machine in advanced. How do you suggest we deal with this?

 

-- I don't like the part about changing the hosts file. if every projects asked me to do it my hosts would look like shit

Well, this won't change - we make heavy use of subdomains in order to implement multi-language support according to google webmaster guidelines, and the dev env should reflect the production environment. Small price to pay, IMHO.

 

-- had to run 'volo add -noprompt' 3 times to get it to work

I have similar volo problems.

 

-- the quickstart doesn't include running the test

It does, it is in:

python manage.py devstrap -m -t

the -t flag runs tests - for sure we can make it clearer.

 

-- the tests fail

-- the local server doesn't work

As we noted when talking earlier - until now, we didn't lock down dependencies as we've been changing things and moving fast - so things break. The break you experienced is from a new release of Whoosh that doesn't work with django-haystack, and, possibly not having redis on your system.

We have now frozen the dependency versions for the project, and added Redis as a dependency. The quickstart is being updated.

 

I left it aside and copied the entities app to a separate repository so I can make it reusable - use it also for the Q&A. It went pretty good - the repo is here - https://github.com/daonb/django-entities, please use it instead of the entities you now have and we can keep improving it together.

That is great.

You can remove serializers.py (only used for the omuni API), translations.py (only used for modifying db tables when modeltranslation is installed), and filters.py (only used by django-filter in the API, we are getting rid of it too), and search_indexes.py (used by django-haystack).

I think it would be nice to give us some credit in the README ;).

I'll start working on the entities app next week and integrate it bak into omuni.

[Paul Walsh]

We updated the upstream HaSadna repo - changes to quickstart, entities docs, and requirements:

https://github.com/hasadna/omuni-budget/commits/develop

Benny, please join the dev group for dev discussions:

https://groups.google.com/forum/#!forum/open-muni-dev

Or even better IMHO, because we now have a common app for two project, maybe it is a good time to start using the general HaSadna dev group that Ido started:

https://groups.google.com/forum/#!forum/hasadna-dev

On Wednesday, 3 July 2013 17:34:45 UTC+3, daonb wrote:

[benny daon]

there's one thing I forgot - directory structure. Django projects share a common structure but not this one. It's both confusing and annoying. I guess it's borrowed from node, but this is not a node project... 

 

- Installation

-- I had to use sudo for "npm install volo"

We wanted to avoid walking people through setting up OS, for reasons like this. Whether you use sudo or not is entirely dependent on how you installed node, and we can't see everyone's machine in advanced. How do you suggest we deal with this?

add a message saying if you got the ..... error try doing it with sudo

 

 

-- I don't like the part about changing the hosts file. if every projects asked me to do it my hosts would look like shit

Well, this won't change - we make heavy use of subdomains in order to implement multi-language support according to google webmaster guidelines, and the dev env should reflect the production environment. Small price to pay, IMHO.

IMHO, you can find a way to do it without forcing me to change my hosts file. i.e. yYou can use Djang's Site framework, allowing me to set the addresses of  the diffrent server.

 

-- had to run 'volo add -noprompt' 3 times to get it to work

I have similar volo problems.

I don't understand what node.js is doing here anyways. Seems like too many frameworks 

 

-- the quickstart doesn't include running the test

It does, it is in:

python manage.py devstrap -m -t

the -t flag runs tests - for sure we can make it clearer.

missed that. Still, I'm used to "python manage.py test" on all the Django projects, are you sure you want your project to use "python manage.py devstrap -t" ?

 

 

-- the tests fail

-- the local server doesn't work

As we noted when talking earlier - until now, we didn't lock down dependencies as we've been changing things and moving fast - so things break. The break you experienced is from a new release of Whoosh that doesn't work with django-haystack, and, possibly not having redis on your system.

We have now frozen the dependency versions for the project, and added Redis as a dependency. The quickstart is being updated.

 

I left it aside and copied the entities app to a separate repository so I can make it reusable - use it also for the Q&A. It went pretty good - the repo is here - https://github.com/daonb/django-entities, please use it instead of the entities you now have and we can keep improving it together.

That is great.

You can remove serializers.py (only used for the omuni API), translations.py (only used for modifying db tables when modeltranslation is installed), and filters.py (only used by django-filter in the API, we are getting rid of it too), and search_indexes.py (used by django-haystack).

I think it would be nice to give us some credit in the README ;).

Right.  Feel free to make the changes and send me a pull request.

 

I'll start working on the entities app next week and integrate it bak into omuni.

Great.

[Paul Walsh]

It has nothing to do with node, I made the structure, and I develop on django and flask, not node.

The 'out of the box' django dir structure is quite annoying IMHO when projects get big: apps sit at the same level as fixtures and settings for example.

The pattern here is much closer to (and initially modeled on) Lincoln Loop's django best practices guide, and other comments I picked up from Alex Gaynor, one of the core django devs as you know, about completely separating apps from the django project directory (I didn't go that far).

So, it is not something from node, but in fact based on patterns out there.

--
You received this message because you are subscribed to the Google Groups "רשויות מקומיות פתוחות- open municipality" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-municipal...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Paul Walsh

0543551144

[benny daon]

That's an interesting question: who's pattern do you follow? 

For me the answer is clear - meir's. I like what he did in Open-Knesset and I follow the pattern in my other projects. You are of course free to structure it the way you see fit, but it will be easier for hasadna developers if our projects shared a pattern.

Benny

http://yeda.us/daonb

[Paul Walsh]

Actually, I'd rather follow a common pattern for HaSadna, for the same reasons, but still, Open Knesset seems to partially be like that due to the way pre django 1.4 projects were structured (manage.py + settings.py).

I am going to talk to Meir about it, thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to open-municipality+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Paul Walsh

0543551144

--
You received this message because you are subscribed to the Google Groups "רשויות מקומיות פתוחות- open municipality" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-municipal...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

http://yeda.us/daonb