Django-autocomplete-light: 3.3.0 is missing vendor directory in static of dal_select2 app

Created on 24 Aug 2018  路  9Comments  路  Source: yourlabs/django-autocomplete-light

This appears to be the same problem as the old bug #620
After rolling back to 3.2.10 everything worked properly.

Thanks!

Most helpful comment

When a new stable version of your upstream dependencies is out, this creates "technical debt" in your project. In eXtreme Programing practice this is considered an "impediment" meaning that no new feature is to be added to the product, until you have upgraded upstream library version.

Supporting both 1.8 and 2.0 is hard. I choose to implement 2.0 support at the cost of dropping 1.8 in my contribution. However, nobody is against compatibility with older versions as long as it doesn't break with newer versions, that hackers should be using.

New contributions to support 1.8 are welcome, as long as they also work for Django 2.0. Note that it's a very good exercise for somebody who wants to learn further than "making django projects" -> the "making of django libs", a very interesting exercise that we highly recommend. Even when, for example when Django 1.8 was out, I had to travel to @blueyed's house for a week, so that we could add 1.8 support by working 5 nights on this project. Not only did I learn a lot from this experience but also made a best friend for life, so that's also a recommended experience: try to team up if you're going to do this.

But in my opinion, all effort that you would put into making new DAL releases compatible with 1.8, python 2, would be better spent porting your project to python3 and Django 2.1 which is released now.

Hope that makes sense and is helpful :joy:

Have a great day,

All 9 comments

I thought 3.3.0 was not vendoring select2 anymore in favor of django.contrib.admin's vendoring of select2.

@jpic Just ran into this issue, and this is making the assumption that everyone is on Django 2.0, which is the first version this became available.

When a new stable version of your upstream dependencies is out, this creates "technical debt" in your project. In eXtreme Programing practice this is considered an "impediment" meaning that no new feature is to be added to the product, until you have upgraded upstream library version.

Supporting both 1.8 and 2.0 is hard. I choose to implement 2.0 support at the cost of dropping 1.8 in my contribution. However, nobody is against compatibility with older versions as long as it doesn't break with newer versions, that hackers should be using.

New contributions to support 1.8 are welcome, as long as they also work for Django 2.0. Note that it's a very good exercise for somebody who wants to learn further than "making django projects" -> the "making of django libs", a very interesting exercise that we highly recommend. Even when, for example when Django 1.8 was out, I had to travel to @blueyed's house for a week, so that we could add 1.8 support by working 5 nights on this project. Not only did I learn a lot from this experience but also made a best friend for life, so that's also a recommended experience: try to team up if you're going to do this.

But in my opinion, all effort that you would put into making new DAL releases compatible with 1.8, python 2, would be better spent porting your project to python3 and Django 2.1 which is released now.

Hope that makes sense and is helpful :joy:

Have a great day,

IIUC, this is also breaking compatibility with Django 1.11, which is the current LTS release. Breaking compatibility with 1.8 seems reasonable since it's no longer a supported release, but it seems like it's much harder to justify breaking 1.11 compatibility.

The justification is: I don't have time for old versions of Django. I wish I had, but I don't. Complain or contribute it's your life, your choice.

I've confirmed the same issue. I notice in git that 3.3.0 rc6 seems to have it, but the released 3.3.0 does not. I've reverted to 3.2.10. @jpic while we too are underfunded to do all the work we wish to do, sometimes that underfunding requires us to defer upgrades that we wish to make. @timmartin if @jpic does not have time to fix this, you might fix it yourself and submit a pull request.

Does it work when you copy the files from django 2.0 admin/static in your project static dir ?

I had a Custom ModelSelect2 autocomplete class, which had:

'autocomplete_light/vendor/select2/dist/css/select2.min.css',

Fixed it by changing it to:

'admin/css/vendor/select2/select2%s.css' % extra,
with

extra = '' if settings.DEBUG else '.min'

on our Django 2.0 branch.
Hope it saves someone some time :)

Please re-open if occurs again on 3.4.0

Was this page helpful?
0 / 5 - 0 ratings