Allow user to pass mongo models file name instead of assuming models.py

[gauravvjn]

in mongonaut/mixins.py Line #87

self.models_name = self.kwargs.get('models_name', 'models')

I have mongo models in mongomodels.py and SQL models in models.py.
so this is not working for me because it try to find mongomodels in models.py

I changed this line and replaced models with mongomodels

self.models_name = self.kwargs.get('models_name', 'mongomodels')

Now I'm able to open page.
earlier i was getting the error AttributeError: 'module' object has no attribute ''.

So I was wondering if there is any way to directly provide mongo models file name in settings or somewhere else.

[devinbarry]

I wrote a fork that solves this problem. Unfortunately I am not supporting old versions of Python or Django in my fork so it cannot be merged back into this repo. Maybe it helps you anyway!
https://github.com/devinbarry/django-mongonaut

[garrypolley]

@devinbarry is there a reason a pull request back to this project can't/won't be made?

It's generally a sign a project will fail if it starts having multiple sources of code. I'd prefer to keep working and updated parts of this library here in one place.

[devinbarry]

Hi @garrypolley. I am happy to make a merge request, its just that it won't be accepted because it breaks backwards compatibility.

The jazzband version of this project doesn't seem like it gets a lot of attention right now and it doesn't define which versions of Python/Django/MongoEngine/Mongo it supports.

In the interests of speedy development I wrote a fork that works with current versions of all of the above, stripping outdated code where appropriate.

So I think the first thing that would be needed is a list of minimum supported version numbers. With such information I could determine if my fork is still compatible. If so then it would be possible to make a merge request.

I guess a project maintainer needs to figure out what to support and what not to support.

[garrypolley]

@devinbarry as you've seen there isn't a lot of support for the project. Other than when a few of us get a chance to review PRs and/or merge them.

If you have a working set of code on latest Django and deps we are happy to upgrade this library. It's better to release a new Major version of this library for folks to use than have two forks, one for new and one for old. That's an area I'd prefer to avoid.

If you don't mind submitting a PR with those changes and a small amount of doc updates specifying the new minimum support versions of the libraries I'm sure we would be happy to take those changes.

I'm not sure who all has access to publish on PyPI though. @pydanny does better than I do on that front.

[devinbarry]

Yes thats a great idea with a new major version. That gives me hope of a successful merge that does not need backwards compatibility. I will work on docs and and tests before I create a PR

[pydanny]

Seeing a major release happen for this library would be awesome! @devinbarry, when you are ready, let us know and we'll merge it in. Then myself or another Jazzband member will put it up on PyPI.

😄

[garrypolley]

We are all very grateful of any contributions folks make. Thanks for taking the time to even update the library. We are happy to help out where we can if you have any questions. Even if you don't feel the code is ready, it looked alright from your branch when I looked at it.

[devinbarry]

I have done some work on the tests in my fork. I have almost all the tests working now. I have also fixed a RuntimeError that exists in the code. Hopefully soon I will be able to make a merge request

[aliasav]

Hello, is there a version that supports Django 1.11.5?
I get an ImportError: cannot import name patterns.

[pydanny]

@aliasav, please don't hijack issues, it makes tracking of requires impossible. Please file your problem in a separate issue.

[aliasav]

Apologies, I'll create a new issue.