new release?

[elguavas]

given that django 1.8 will be released soon, how are things going for a new pip installable release of mezzanine that supports django 1.7?

i'm also very interested in the new fabfile stuff for shared host installs.

i'm also wondering, with mezz almost missing a whole django version without a pip installable release, are things on the mezz release front likely to continue to be very slow in staying up to date with changes in mezz git?

not intending to be critical, not at all, just looking for an honest assessment of how the project is faring with respect to official releases. cheers.

[Eduardo Rivas]

Hi. I'm sharing my personal viewpoint (wait for Steve to give a official statement):

• My appreciation is that catching up with Django 1.7 is taking a lot because it introduces a lot of backwards-incompatible changes AND Mezzanine wants to keep supporting Django 1.6 too. With 1.8 we might not have the same problem, because we probably won't be seeing so many breaking changes. Also, the next release will have Model translation support, which is huge too!
  
• A warning related to the Fabric script: it will only work if you have sudo privileges on the remote server. I'm mentioning this because shared hosting accounts often lack this privilege.

[Asif Saifuddin]

Why not a version 3.2 with dj 1.7 and 1.8 support?

[Ken Bolton]

On Tue, Mar 24, 2015 at 8:46 AM, Asif Saifuddin <auv...@gmail.com> wrote:

Why not a version 3.2 with dj 1.7 and 1.8 support?

Django has a glorious history of supporting the three most recent point releases. Mezzanine, appropriately, continues that by releasing versions that support the currently-supported versions of Django. This has always been, in my opinion, the sensible way to approach releases. Right now, support for Django 1.5 is far more important. If support were dropped for 1.5, this would make Mezzanine much less valuable for those of us who have relied on stable releases for five years.

If you absolutely need some feature in 1.7, you have two options: 1. use master or 2. fix the outstanding issues that are blocking a release.

1.8 support is right out. Asking for it is a distraction from the important work of the contributors and maintainers.

- ken

[Stephen McDonald]

Apologies for the delay, I'm currently on vacation overseas with my wife and children over the next month.

On Tue, Mar 24, 2015 at 10:06 AM, elguavas <elgu...@gmail.com> wrote:

given that django 1.8 will be released soon, how are things going for a new pip installable release of mezzanine that supports django 1.7?

The so-far skipping of an official release against Django 1.7 is a valid concern. Basically as Ed mentioned, the breaking changes from Django 1.6 to 1.7 were much larger than normal. I vaguely recall that around the time the first Django 1.8 alpha release was made, we still had outstanding 1.7 incompatibilities, so at that point the question (in my head at least) was raised around how worthwhile it would be to spend time on working toward an official release against 1.7 given that the 1.8 release would be coming soon. The alternative being that we just focus effort on compatibility with 1.8, and hopefully everything would line up compatibility-wise in time for the official 1.8 release. As of a few weeks ago, we actually have 1.8 compatibility working - that may have changed since then, but given that sign, it appears that the transition from 1.7 to 1.8 will require much less effort. 

As Ken said this would normally not be a consideration right now, but given how things have turned out, we will most likely release Mezzanine 3.2 with support for Django 1.7 and 1.8, along with the new modeltranslation work, right after the release of Django 1.8.

 

i'm also very interested in the new fabfile stuff for shared host installs.

i'm also wondering, with mezz almost missing a whole django version without a pip installable release, are things on the mezz release front likely to continue to be very slow in staying up to date with changes in mezz git?

not intending to be critical, not at all, just looking for an honest assessment of how the project is faring with respect to official releases. cheers.

I don't mean to sound critical either, and I appreciate the desire for some clarity here, but I always find this type of question misguided. 

There's no corporate entity behind Mezzanine with a fixed schedule of time and resources that can be dedicated to it, which is precisely what would be required to answer this question definitively. Its development relies on the always-varying amount of free time myself and the other contributors can make available to it. I simply don't have a crystal ball I can peek into to provide you with any more clarity than that. 

As mentioned above, the move from Django 1.6 to 1.7 required a non-trivial amount of effort, which was a huge setback. Meanwhile the move from 1.7 to 1.8 has been almost seamless. So really you could flip a coin as to what the future looks like - we're really at the mercy of Django's development.

That said, there are a couple of things *you* can do to make our timelines less erratic. As often requested, please help out in resolving these incompatibilities when new alphas/betas/RCs of Django are made available. If enough people were to identify and resolve these issues earlier on, sailing would be much smoother. Another idea is that we only really see these problems very late into the Django development cycle. What we really need is a voice within the Django development space - if someone was there early on enough to say "hey this is going to be a huge breaking change", perhaps more care for backward compatibility could be taken. I hope this doesn't sound like a criticism of Django, they can't know what they're breaking if no one tells them.

Thanks for bringing this up - I hope I've been able to make things a tiny bit clearer for everyone who has been questioning the lapse in releasing.

 

--
You received this message because you are subscribed to the Google Groups "Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Stephen McDonald
http://jupo.org

[Asif Saifuddin]

I thing could be maiking 3.1.x series LTS and Having a 3.2 release after 1.8 release and other work arrounds. like wagtail-cms team is doing.

enjoy the vacation!

Thank you for all your effort behind mezzanine.

Kind regards 

--
You received this message because you are subscribed to a topic in the Google Groups "Mezzanine Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mezzanine-users/_QWfFVB3RVc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mezzanine-use...@googlegroups.com.

[elguavas]

> I hope this doesn't sound like a criticism of Django, they can't know what they're breaking if no one tells them.

yep, it's hard to question a lot of things about other libre/open source projects without seeming ungrateful.

i'm a libre software developer myself so i'm keenly aware of all the problems resulting from the reality of time strapped volunteers and trying to release in a timely fashion.

> I hope I've been able to make things a tiny bit clearer for everyone who has been questioning the lapse in releasing.

i can't speak for anyone else but for me the question was really "is it thought the current release situation with mezz an anomaly or that the pace of django change is gonna cause ongoing problems?",  so that's been fully and clearly addressed by Ed and yourself. thanks.

and i echo Asif's sentiments with please enjoy your holiday and thanks a huge bunch for all your fantastic effort on mezz so far, it's great software. ;)

[Micah Yoder]

Indeed, thank you to all involved. I've also been watching, a bit anxiously, for a 1.7 based release. Now 1.8. Kind of hate to do much work on current site when big changes are coming. :)

I probably should jump in and see if I could help with fixing anything. I'm sure it would teach me a lot. (Out on vacation myself for 3 weeks though.)

[Stephen McDonald]

Just a status update on the next release.

I've just removed all support for South and Django 1.6 and earlier. Please help me with a review and fixing anything I may have overlooked:

https://github.com/stephenmcd/mezzanine/commit/955488361b17959df80ae64e2cb9a2830d7f4540

https://github.com/stephenmcd/mezzanine/commit/90912aff8a2858ac4466d8d4677e5be5d9da149f

I'm currently getting an error with the `createdb` command against 1.8 (but not 1.7) - if anyone wants to try and work that out it'd be awesome.

Again, could *really* use help in testing the current dev branch against Django 1.7 and 1.8 - let's get this next release bullet proof against them!

Once the above is sorted, I'll release the official new version, supporting Django 1.7 and 1.8. Perhaps we'll call it Mezzanine 4 rather than 3.2, it feels large enough to warrant a magical bump in the major version number.

[Graham]

Hi Stephen
When you say
'Again, could *really* use help in testing the current dev branch against Django 1.7 and 1.8'
Is there anything I can look at to know how to do this?
TIA
Graham

[Stephen McDonald]

Thanks Graham - I guess it mostly involves working with a virtualenv for each Django version, as well as using pip in each of those to install Mezzanine directly from Github or BitBucket. There's probably a ton of info online that better describes how to do that. 

With that in place, next step is to create a project in each, run them, do things to them. Wild things. Try and break it. Use your existing projects. Use all the features from an end use perspective. Make custom content types, the works. I really can't be too prescriptive here, all I'd do is repeat my own process which would be redundant. Be creative.

[Graham]

ok
How about Python versions?
2.7.9 and 3.4.3
Does that sound right?
g

[Stephen McDonald]

Absolutely, I totally forgot to mention that.

[Mathias Ettinger]

One hint for the createdb error with Django 1.8 : https://docs.djangoproject.com/en/1.8/howto/custom-management-commands/#django.core.management.NoArgsCommand
-> the error is caused by the fact that the options dictionnary passed to the handle_noargs method does not include a 'database': 'default' entry anymore.


You may also be interested in refactory settings.py according to https://github.com/django/django/blob/1.7.7/django/core/checks/compatibility/django_1_6_0.py to remove annoying warnings with Django 1.7

[Eduardo Rivas]

As you can see in the file linked by Mathias, you can get rid of the test runner warning by overriding a setting:

TEST_RUNNER = 'django.test.runner.DiscoverRunner'

The docstring of the function that performs the check seems to support the assumption that this setting should be overridden, so I think it is an acceptable fix.

[Eduardo Rivas]

Here's my take on the createdb issue. The version checking feels dirty, but it works. https://github.com/stephenmcd/mezzanine/pull/1247

[Graham Oliver]

Just adding this to this thread. Let me know if it should go elsewhere
Django 1.8, Python 3.4.3
When I do python manage.py runserver

1) I get many of these 'RemovedInDjango19Warning'

also....

2) I get this warning
WARNINGS:
core.SitePermission.user: (fields.W342) Setting unique=True on a ForeignKey has the same effect as using a OneToOneField.
    HINT: ForeignKey(unique=True) is usually better served by a OneToOneField.

[Graham Oliver]

Django 1.7.7, Python 3.4.3

python manage.py runserver

Performing system checks...

System check identified some issues:

WARNINGS:
?: (1_6.W001) Some project unittests may not execute as expected.
    HINT: Django 1.6 introduced a new default test runner. It looks like this project was generated using Django 1.5 or earlier. You should ensure your tests are all running & behaving as expected. See https://docs.djangoproject.com/en/dev/releases/1.6/#new-test-runner for more information.

System check identified 1 issue (0 silenced).

You have unapplied migrations; your app may not work properly until they are applied.
Run 'python manage.py migrate' to apply them.

[Graham Oliver]

Same results on Python 2.7.9

I notice that all of the 4 tests except the first one had this text

'You have unapplied migrations; your app may not work properly until they are applied.
Run 'python manage.py migrate' to apply them.'

[David Unric]

Can confirm, exactly same warning messages.

[Graham Oliver]

Django 1.8 - Python 3.4.3
Took the advice of the console 'You have unapplied migrations; your app may not work properly until they are applied.

Run 'python manage.py migrate' to apply them.'

and ran python manage.py migrate

stack trace

Running migrations:
  Rendering model states...Traceback (most recent call last):
  File "manage.py", line 28, in <module>
    execute_from_command_line(sys.argv)
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
    utility.execute()
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/core/management/__init__.py", line 330, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/core/management/base.py", line 390, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/core/management/base.py", line 441, in execute
    output = self.handle(*args, **options)
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/core/management/commands/migrate.py", line 221, in handle
    executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/db/migrations/executor.py", line 100, in migrate
    state.apps  # Render all real_apps -- performance critical
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/utils/functional.py", line 60, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/db/migrations/state.py", line 154, in apps
    return StateApps(self.real_apps, self.models)
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/db/migrations/state.py", line 220, in __init__
    self.render_multiple(list(models.values()) + self.real_models)
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/django/db/migrations/state.py", line 258, in render_multiple
    "for more" % (new_unrendered_models, get_docs_version())
django.db.migrations.state.InvalidBasesError: Cannot resolve bases for [<ModelState: 'soulapp2.SoulPractitioner'>, <ModelState: 'soulapp2.SoulClassInformation'>, <ModelState: 'soulapp2.Happening'>]
This can happen if you are inheriting models from an app with migrations (e.g. contrib.auth)
 in an app with no migrations; see https://docs.djangoproject.com/en/1.8/topics/migrations/#dependencies for more

*Note*
The 3 models mentioned are the only ones in the project that inherit from 'Page' and 'RichText'

[Mathias Ettinger]

Do you have migration defined in your soulapp2 application?

If not, it is standard Django behaviour. The doc says:
Be aware, however, that unmigrated apps cannot depend on migrated apps, by the very nature of not having migrations. This means that it is not generally possible to have an unmigrated app have a ForeignKey or ManyToManyField to a migrated app; some cases may work, but it will eventually fail.

--
You received this message because you are subscribed to a topic in the Google Groups "Mezzanine Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mezzanine-users/_QWfFVB3RVc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mezzanine-use...@googlegroups.com.

[Graham]

No I don't so I will need to do something to stop the errors occuring
I was thinking something along these lines.... Does that look right?
https://docs.djangoproject.com/en/1.8/topics/migrations/#upgrading-from-south

You received this message because you are subscribed to the Google Groups "Mezzanine Users" group.

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

[Mathias Ettinger]

If you never created migration for south, it might be possible that you won't even have to use the --fake-initial option. But yeah, it is the way to go.

[Graham]

ok thanks
This worked for me

1. pip install south

2. python manage.py makemigrations soulapp2 (note that the Django documentation is incorrect according to the first answer here http://stackoverflow.com/questions/24912173/django-1-7-makemigrations-not-detecting-changes)

3. python manage.py migrate --fake-initial

4. pip uninstall south

Thanks
g

[Graham Oliver]

Django 1.8
Python 3.4.3

Accessing the admin

ImportError at /admin/login/

cannot import name 'find_template_loader'

Request Method:	GET
Request URL:	http://127.0.0.1:8000/admin/login/?next=/admin/
Django Version:	1.8
Exception Type:	ImportError
Exception Value:	cannot import name 'find_template_loader'
Exception Location:	/home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages/mezzanine/template/loader_tags.py in find_template, line 62
Python Executable:	/home/graham/.pyenv/versions/py3.4.3-dj1.8/bin/python
Python Version:	3.4.3
Python Path:	['/home/graham/Dropbox/mp-soul-2', '/home/graham/.pyenv/versions/3.4.3/lib/python34.zip', '/home/graham/.pyenv/versions/3.4.3/lib/python3.4', '/home/graham/.pyenv/versions/3.4.3/lib/python3.4/plat-linux', '/home/graham/.pyenv/versions/3.4.3/lib/python3.4/lib-dynload', '/home/graham/.pyenv/versions/py3.4.3-dj1.8/lib/python3.4/site-packages', '/home/graham/Dropbox']
Server time:	Thu, 9 Apr 2015 15:19:14 +1200

Error during template rendering

In template /home/graham/Dropbox/mp-soul-2/soulapp2/templates/admin/base_site.html, error at line 1

cannot import name 'find_template_loader'

1	{% overextends "admin/base_site.html" %}

[Stephen McDonald]

That was resolved a few months ago:

https://github.com/stephenmcd/mezzanine/commit/a50de50699bb6a24bfb5f118449991aa7608b426

It looks like you're using the current 3.1.10 release of Mezzanine,
rather than the development branch from Github.

> error at line *1*

> cannot import name 'find_template_loader' 1 {% overextends
> "admin/base_site.html" %}
>

> --
> You received this message because you are subscribed to the Google Groups
> "Mezzanine Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mezzanine-use...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


--

Stephen McDonald
http://jupo.org

[Graham]

oops sorry
will sort
g

[Graham]

Hi Stephen
I think I am using the up to date version of the code, namely

try:
# Django >= 1.8
find_template_loader = context.engine.find_template_loader
except AttributeError:
# Django <= 1.7
print ("hello")
from django.template.loaders import find_template_loader

prints hello

This does not fit the logic of the comments because the Django version
is 1.8

g



On 09/04/15 15:59, Stephen McDonald wrote:

[Stephen McDonald]

My apologies, I was wrong earlier - looks like this code's really broken in 1.8. I'm not across so I'm not sure why, but I'll open an issue for it.

Thanks a lot.

email to mezzanine-users+unsubscribe@googlegroups.com.

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

--
You received this message because you are subscribed to the Google Groups "Mezzanine Users" group.

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

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

[Stephen McDonald]

I've actually added a new issue label called "release blockers" to the issue tracker, which contains the new issue just discussed here.

https://github.com/stephenmcd/mezzanine/issues?q=is%3Aopen+is%3Aissue+label%3A%22release+blocker%22

So now we can track exactly what's left to do before the next release.

Thanks again Graham!

On Thu, Apr 9, 2015 at 2:34 PM, Graham <greenba...@gmail.com> wrote:

email to mezzanine-users+unsubscribe@googlegroups.com.

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

--
You received this message because you are subscribed to the Google Groups "Mezzanine Users" group.

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

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

[Graham]

All good.
g

email to mezzanine-use...@googlegroups.com.

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

--
You received this message because you are subscribed to the Google Groups "Mezzanine Users" group.

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

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

--

Stephen McDonald
http://jupo.org

--
You received this message because you are subscribed to the Google Groups "Mezzanine Users" group.

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

[Alexander Hill]

Thanks for the report Graham - a fix for this has just been applied to master.

Cheers,

Alex

[Stephen McDonald]

Big thanks to Alex Hill who's worked out the fix for the issue last reported here - if you're testing, please pull the latest in again and give it a whirl.

[Graham Oliver]

All good on Python 3.4.3 and Django 1.8
When I switch to Python 3.4.3 and Django 1.77 I get this stack trace when doing 'python manage.py runserver'

Unhandled exception in thread started by <function check_errors.<locals>.wrapper at 0x7ff18c8aba60>

Traceback (most recent call last):

  File "/home/graham/.pyenv/versions/py3.4.3-dj1.7.7/lib/python3.4/site-packages/django/utils/autoreload.py", line 222, in wrapper
    fn(*args, **kwargs)
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.7.7/lib/python3.4/site-packages/mezzanine/core/management/commands/runserver.py", line 154, in inner_run
    super(Command, self).inner_run(*args, **kwargs)
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.7.7/lib/python3.4/site-packages/django/core/management/commands/runserver.py", line 107, in inner_run
    self.check_migrations()
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.7.7/lib/python3.4/site-packages/django/core/management/commands/runserver.py", line 159, in check_migrations
    executor = MigrationExecutor(connections[DEFAULT_DB_ALIAS])
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.7.7/lib/python3.4/site-packages/django/db/migrations/executor.py", line 17, in __init__
    self.loader = MigrationLoader(self.connection)
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.7.7/lib/python3.4/site-packages/django/db/migrations/loader.py", line 48, in __init__
    self.build_graph()
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.7.7/lib/python3.4/site-packages/django/db/migrations/loader.py", line 177, in build_graph
    self.load_disk()
  File "/home/graham/.pyenv/versions/py3.4.3-dj1.7.7/lib/python3.4/site-packages/django/db/migrations/loader.py", line 103, in load_disk
    migration_module = import_module("%s.%s" % (module_name, migration_name))
  File "/home/graham/.pyenv/versions/3.4.3/lib/python3.4/importlib/__init__.py", line 109, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 2254, in _gcd_import
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2226, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1129, in _exec
  File "<frozen importlib._bootstrap>", line 1471, in exec_module
  File "<frozen importlib._bootstrap>", line 321, in _call_with_frames_removed
  File "/home/graham/Dropbox/mp-soul-2/soulapp2/migrations/0001_initial.py", line 11, in <module>
    class Migration(migrations.Migration):
  File "/home/graham/Dropbox/mp-soul-2/soulapp2/migrations/0001_initial.py", line 36, in Migration
    ('objects', mezzanine.pages.managers.PageManager()),
TypeError: __init__() got an unexpected keyword argument 'managers'

cheers
g

[Graham Oliver]

Can't reproduce
No longer consider this a problem
g

[Graham Oliver]

Python 3.4  Django 1.8

Request Method:	GET
Request URL:	http://192.168.1.81:8000/search/?q=samoa
Django Version:	1.8
Exception Type:	TypeError
Exception Value:	unsupported operand type(s) for |=: 'list' and 'list'
Exception Location:	/home/graham/Virtual-Environments/test-py3-dj1.8/lib/python3.4/site-packages/mezzanine/core/managers.py in search, line 265
Python Executable:	/home/graham/Virtual-Environments/test-py3-dj1.8/bin/python

I will do some digging
g

[Graham Oliver]

no problems in 1.7.7
Here is the return from the [m._meta.get_parent_list() for m in models] in 1.7.7
[{<class 'mezzanine.pages.models.Page'>}, {<class 'mezzanine.pages.models.Page'>}, {<class 'mezzanine.pages.models.Page'>}, set(), {<class 'mezzanine.pages.models.Page'>}, set(), {<class 'mezzanine.pages.models.Page'>}, {<class 'mezzanine.pages.models.Page'>}, {<class 'mezzanine.pages.models.Page'>}]

Here is the same return in 1.8
[[<class 'mezzanine.pages.models.Page'>], [<class 'mezzanine.pages.models.Page'>], [<class 'mezzanine.pages.models.Page'>], [], [<class 'mezzanine.pages.models.Page'>], [], [<class 'mezzanine.pages.models.Page'>], [<class 'mezzanine.pages.models.Page'>], [<class 'mezzanine.pages.models.Page'>]]

cheers
g


My best guess is that it is something to do with

[Stephen McDonald]

Good find Graham, thanks a lot for tracking it down.

That's fixed now:

https://github.com/stephenmcd/mezzanine/commit/3ad1a6a9ce049e14fe9d120be1226844ad201baf

--
You received this message because you are subscribed to the Google Groups "Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Graham Oliver]

ok retested on Django 1.77 and 1.8 - all is good

[Gavin Wahl]

Is there a timeline for a release that supports Django 1.8?

[Graham Oliver]

Hi Gavin
My understanding is that it is done on a best-efforts basis, so the short answer to your question is 'no'.
Cheers
g

[Eduardo Rivas]

Also, you can take a look at the issues marked as "release blocker" in
the issue tracker to get a sense of what is actually keeping the next
release from happening.

[Micah Yoder]

Hi,

I've been trying to test out the upstream master code. I have a Python 3.4.3 virtualenv with django 1.8. When getting to the createdb step I'm getting this error:

 File "/home/micah/testsite/venv/lib/python3.4/site-packages/django/db/migrations/loader.py", line 174, in build_graph
   self.load_disk()
 File "/home/micah/testsite/venv/lib/python3.4/site-packages/django/db/migrations/loader.py", line 91, in load_disk
   for name in os.listdir(directory):
NotADirectoryError: [Errno 20] Not a directory: '/home/micah/testsite/venv/lib/python3.4/site-packages/django_contrib_comments-1.6
.0-py3.4.egg/django_comments/migrations'

That egg file definitely exists and the django_comments/migrations directory exists within it.

I asked on IRC a few days ago and Stephen helpfully replied that I needed the git master version of django-contrib-comments.  I grabbed that and installed it and indeed that resolved the issue.  However, I then hit another error, representing an "out-of-sync" between Mezzanine and django-contrib-comments, which Stephen quickly fixed. Nice!  Unfortunately, after I installed it, the above error came back. And that's where I still am. :/

Yes, I've re-installed the django-contrib-comments.  In fact I just now pulled the latest mezzanine and django-contrib-comments, installed them in that order, and I still get it.

Any idea what's up/

Thanks!

Not a django expert but would like to get there. :)

[Stephen McDonald]

This looks like a packaging issue with the comments app, I've provided them with a fix here:

https://github.com/django/django-contrib-comments/pull/40

If you'd like to make use of that now, you can specify my fork of the comments app in the above PR as your dependency.

--
You received this message because you are subscribed to the Google Groups "Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sreedhar Bukya]

Hi, 

My current project is working on Django 1.6.1 and mezzanine 3.0.8. 

This is the first time I am doing package upgrade. I am thinking to upgrade Django 1.8 in steps (first 1.7 then 1.8) and mezzanine to latest version both. 

What are the things i need to take care to complete upgrade?

If you could provide me some insights I  will be glad. 

Regards, 

Sreedhar 

On Tuesday, 24 March 2015 04:36:32 UTC+5:30, elguavas wrote:

given that django 1.8 will be released soon, how are things going for a new pip installable release of mezzanine that supports django 1.7?

i'm also very interested in the new fabfile stuff for shared host installs.

i'm also wondering, with mezz almost missing a whole django version without a pip installable release, are things on the mezz release front likely to continue to be very slow in staying up to date with changes in mezz git?

not intending to be critical, not at all, just looking for an honest assessment of how the project is faring with respect to official releases. cheers.

[Micah Yoder]

Yay, I just made that change manually in my copy and that fixed it! Thanks!
Surely I'm not the first person who ran into that???

[Graham Oliver]

Hello everyone
Using PostgreSQL in a virtual environment
When I go through the install process for the mezzanine.jupo.org web site I am encountering a problem with the latest Django version 1.8.2
Note the problem does *not* occur with 1.7.8

Here is a description and stack trace of the problem
https://github.com/stephenmcd/mezzanine.jupo.org/issues/6

I managed to get the install to work by running
python manage.py migrate auth (even though this exits with an error)
before the createdb command

I got that idea from http://stackoverflow.com/questions/29689365/auth-user-error-with-django-1-8-and-syncdb-migrate

Cheers
g

p.s. I had to upgrade django-compressor to the latest version (1.5) to work around another problem

[Mathias Ettinger]

What happens if you swap django.contrib.auth and django.contrib.admin in your INSTALLED_APPS? Does it solves it without the extra step?

[Graham]

The problem remains the same :-(
g

On 28/05/15 19:13, Mathias Ettinger wrote:
> What happens if you swap django.contrib.auth and django.contrib.admin in your INSTALLED_APPS? Does it solves it without the extra step?
>

--
T : 021 081 71732

[elguavas]

bump ;)  i just looked in the issue tracker under "release blockers" and i said there were zero.

[Graham Oliver]

I raised this issue https://groups.google.com/d/msg/mezzanine-users/_QWfFVB3RVc/kar0ykEMZzgJ
In terms of a new release I am not sure of its impact (if any).
g