We thus separate what concerns python dependencies install, and the work-in-progress code to be mounted inside the VM.

Having a COPY of the whole code and THEN a mountpoint on same folder is dangerous, because mount failure would be a silent error, and lead to hard-to-debug wrong behaviour.

After reading this post: https://medium.com/3yourmind/keeping-django-database-migrations-backward-compatible-727820260dbb

Maybe we should add next libraries:

• https://github.com/3YOURMIND/django-add-default-value
• https://github.com/3YOURMIND/django-deprecate-fields
• https://github.com/3YOURMIND/django-migration-linter

It is just released: https://docs.djangoproject.com/en/2.2/releases/2.2/

Let's do it!

• [x] Check libraries compatibility with django>=2.2
• [ ] Upgrade source code at project

I launched a project. After creating the model, I'm trying to run tests. But I get an error.

ERROR collecting server/apps/main/admin.py 
server/apps/main/admin.py:12: in <module>
    admin.site.register(File, Dd)
.venv/lib/python3.7/site-packages/django/contrib/admin/sites.py:110: in register
    raise AlreadyRegistered('The model %s is already registered' % model.__name__)
E   django.contrib.admin.sites.AlreadyRegistered: The model File is already registered

ERROR collecting server/apps/main/models.py 
server/apps/main/models.py:28: in <module>
    class File(AbstractDefaultModel):
.venv/lib/python3.7/site-packages/django/db/models/base.py:118: in __new__
    "INSTALLED_APPS." % (module, name)
E   RuntimeError: Model class main.models.File doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS.

my code models.py

class AbstractDefaultModel(models.Model):
    is_active = models.BooleanField(
        verbose_name=_('is_active'),
        default=True)

    created_at = models.DateTimeField(
        verbose_name=_('created at'),
        auto_now_add=True)

    updated_at = models.DateTimeField(
        verbose_name=_('updated at'),
        auto_now=True)

    def __str__(self):
        return '{id}'.format(id=self.id)

    class Meta:
        abstract = True

class File(AbstractDefaultModel):
    code = models.PositiveIntegerField(
        verbose_name='code',
        unique=True,
        editable=True)

    profile = models.CharField(
        verbose_name='name',
        max_length=100,
        blank=True,
        null=True)

    class Meta:
        verbose_name = 'file'
        verbose_name_plural = 'files'

my code admin.py

from server.apps.main.models import File
class FileAdmin(admin.ModelAdmin):
    list_display = ['id', 'profile']

admin.site.register(File, FileAdmin)

Trying to run docker-compose build && docker-compose up gives an error: test_project exited with code 127. I see ': No such file or directory'sh in the console output and since the error code 127 also is related to unknown command there seem to be something wrong with the dockerfile related to django.

I'm testing this on Windows 10.

Bumps ipython from 7.31.0 to 8.0.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Hello,

When I run in the following command in development mode.

docker-compose -f docker-compose.yml -f docker-compose.dev.yml run --rm web python manage.py makemigrations

I get in the following error; "Permission denied: '/code/server/apps/main/migrations/0002_blogpost_is_ok.py'"

I'm using Linux.

Hi. I faced a very hard work when changing the database engine. Maybe we should call these variables in a more general way?

example: DB_NAME=mydb DB_USER=myuser DB_PASSWORD=mypass

Bumps flake8-pytest-style from 1.4.0 to 1.4.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

We have this awesome little tool to setup Gitlab projects that perfectly matches this template. It is called kira-setup and it is a part of kira bots family.

We can mention it in the docs. Maybe someone will find it useful. Link: https://github.com/wemake-services/kira-setup

Docker on start announces Starting development server at http://0.0.0.0:8000/. It is wrong and it is available under http://127.0.0.1:8000/. This should be reflected somewhere in documentation.

This PR contains the following updates:

| Package | Update | Change | |---|---|---| | postgres | major | 14-alpine -> 15-alpine |

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

• [ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• [ ] Update postgres Docker tag to v15

Detected dependencies

• [ ] Check this box to trigger a request for Renovate to run again on this repository

Yesterday I found that a single django test case in my private project was modifying os.environ without a clean up.

It was the root cause of flaky CI builds that happened like once a week (because of random test order).

Now, this won't happen: https://github.com/wemake-services/pytest-modified-env