Is django-multiselectfield dead?

[MartinThoma]

The last commit is quite a while ago and I see 32 open issues and 11 open PRs. Some of them seem rather important.

Is this package dead?

If so, what do people use instead?

[olivierdalang]

On my fork I have tests passing on Django 4.1-5.0 and recent python : https://github.com/olivierdalang/django-multiselectfield

(haven't tested much so far, but with the tests and the demo project working, I guess it should be usable)

[aliceni81]

On my fork I have tests passing on Django 4.1-5.0 and recent python : https://github.com/olivierdalang/django-multiselectfield

(haven't tested much so far, but with the tests and the demo project working, I guess it should be usable)

The current version is incompatible with Django 5.0. There is no _get_flatchoices in django's CharField anymore, instead Django provides flatchoices directly. Therefore, the following code in db/fields.py should be removed.

def _get_flatchoices(self):
        flat_choices = super(MultiSelectField, self)._get_flatchoices()

        class MSFFlatchoices(list):
            # Used to trick django.contrib.admin.utils.display_for_field into
            # not treating the list of values as a dictionary key (which errors
            # out)
            def __bool__(self):
                return False
            __nonzero__ = __bool__
        return MSFFlatchoices(flat_choices)
flatchoices = property(_get_flatchoices)

[lightswitch05]

@tomasgarzon @goinnn instead of going the fork route, could someone else be given permissions to merge? Django 3.2 goes EOL in the spring, it would be really nice to get some of those bugfix PRs merged. I would be happy to help with that too if needed.

[christoph-teichmeister]

@tomasgarzon @goinnn instead of going the fork route, could someone else be given permissions to merge? Django 3.2 goes EOL in the spring, it would be really nice to get some of those bugfix PRs merged. I would be happy to help with that too if needed.

@aliceni81, instead of forking and as a quickfix, you could also overwrite the failing method yourself in your project:

from multiselectfield import MultiSelectField as MSField

class MultiSelectField(MSField):
    """
    Custom Implementation of MultiSelectField to achieve Django 5.0 compatibility

    See: https://github.com/goinnn/django-multiselectfield/issues/141#issuecomment-1911731471
    """

    def _get_flatchoices(self):
        flat_choices = super(models.CharField, self).flatchoices

        class MSFFlatchoices(list):
            # Used to trick django.contrib.admin.utils.display_for_field into not treating the list of values as a
            # dictionary key (which errors out)
            def __bool__(self):
                return False

            __nonzero__ = __bool__

        return MSFFlatchoices(flat_choices)

    flatchoices = property(_get_flatchoices)

...and then use that field in your project 🙂

Also remember to update your import paths in any existing migrations to point to your new field-implementation, as otherwise, rebuilding your db will fail!

[PetrDlouhy]

I think the best would be to transition this package under Jazzband. @blag @goinnn @tomasgarzon Would you be willing to give needed cooperation, if somebody would prepare this project for such transition?

@olivierdalang Could you make PR here with the GitHub testing?

[chrcorn]

@PetrDlouhy I sent an email to @goinnn and he is planning on updating this package, some time this year. Don't know when exactly. I did offer help to update this package if he wants to but I am waiting a reply on my offer

I suggest that for now you can use my repo (https://github.com/spnshguy/django-multiselectfield) until there is an update for this package

[PetrDlouhy]

@chrcorn That is great news, thanks.

I think that moving to Jazzband would be the ultimate solution. Anyway, if there is anything how I can help with the transition or the release, please ask.

I would like to phase out non-PyPI packages from my project, so I would rather wait for Django 5.0 update. Also it is not good solution for other applications depending on this package, like django-admin-charts. I can't merge this PR before this is resolved: https://github.com/PetrDlouhy/django-admin-charts/pull/73

[olivierdalang]

Could you make PR here with the GitHub testing?

@PetrDlouhy here you go: https://github.com/goinnn/django-multiselectfield/pull/147

[PetrDlouhy]

Thank you very much @olivierdalang

@chrcorn I think you can now write @goinnn to merge #147 first. It should be very simple and risk free. Than all other PRs could be rebased on top of that.

[blag]

Former maintainer here. I'm also a member of Jazzband. Last time I emailed privately with @goinnn they expressed interest in turning this project over to Jazzband, and they took that opportunity to not remove me from maintainer access on GitHub and PyPI. So I'll assume both of those things are still true.

I don't really have the time to maintain this package as much as I used to, but if I can get multiple people to review and sign off on PRs, I will try to prioritize reviewing and merging them. If we need a new release to PyPI, I can attempt that as well (although I would absolutely be appreciative of a PR that automates that with GHA!).

Thanks.

[PetrDlouhy]

@blag Excellent. Can you start with #147? I hope there is not much decision needed about adding working testing setup. I tried to put a positive review there, but it doesn't seem to appear there (maybe there some permission issue?).

As of Jazzband - does it need to be @goinnn himself to submit project proposal? https://github.com/jazzband/help/issues/new/choose

[PetrDlouhy]

@blag Could you please look at GitHub actions testing in #147 first? Then we could merge the updates more easily.

Or I could do it, if I would be given the permissions.

[blag]

#147 is merged. What can/should I review next?

[blag]

Can I get a second set of eyes on #148?

[blag]

Closing, since it's not dead quite yet.

[PetrDlouhy]

@blag Is there any work needed to do in order to release new version?

Also, I made #151, if you find time to check. But it doesn't have influence on the working code, so there is no need for merging that before release.