Re: GitHub Actions

[Johannes Hoppe]

Hi Mariusz,

Cool, let me know if you have any questions about the config file that I wrote. 
I am happy to help :)

Regarding the output, yes I can feel you. However I don’t know if we really 
need to run tests at verbosity level 2 on CI. One can always do that online or 
enable it if need be.

At list of tests that failed in a human readable output format would be nice. 
GitHub supports annotation on checks, but it's not really convenient yet to be 
used.

Using it for linters is a good start. We could also do the docs build and limit 
that one to be only build if the docs actually changed. You can trigger builds 
based on file condition, which is pretty neat.

Something that we also haven’t explored are scheduled builds. Those could be 
helpful to do regression tests on especially on dependencies.

Anyhow, love to see where this is going.
-Joe
On 11. Nov 2019, 15:53 +0900, Mariusz Felisiak , 
wrote:
>
> > I would suggest to open a PR to GitHub now and to get the Fellows involved. 
> > Ask them how to best integrate a trial without disturbing their workflow. 
> > What do you guys think?
> >
>
> I'm going to play with GitHub actions in this week (or in the next one) but 
> I'm still not convinced. It's fine to use them for linters, but for more 
> complicated jobs it generates output that is less readable, IMO. You don't 
> get a formatted table but a raw output, so you have to scroll down ~20k lines 
> to check what went wrong. This can be really frustrating especially with more 
> then one failure. Nevertheless I'm going to play with it.
>
> Best
> Mariusz
>
>
> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/django-developers/xDCmZPLTOQQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/6692d50f-b02d-4824-aa12-be22a20c3f0f%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2f94ae46-4345-46a2-9a1c-fcdce164cc1f%40Spark.

Fellow Reports - November 2019

[Mariusz Felisiak]

Week ending November 10, 2019.

Released Django 2.2.7, 2.1.14, and 1.11.26.

*Triaged:*
https://code.djangoproject.com/ticket/27808 - Nested ArrayField with 
nullable base field generates invalid SQL. (fixed)
https://code.djangoproject.com/ticket/30942 - first() and last() return 
same object (first in both cases) when the order_by field is the same 
(duplicate)
https://code.djangoproject.com/ticket/30943 - Add support for bloom 
indexes. (accepted)
https://code.djangoproject.com/ticket/30946 - Hebrew translation of "This 
password is too short." message (invalid)
https://code.djangoproject.com/ticket/30949 - Use functools.cached_property 
instead of django.utils.functional.cached_property. (Someday/Maybe)
https://code.djangoproject.com/ticket/30951 - Admin Documentation 
recommends an incorrect method to get selected objects. (duplicate)
https://code.djangoproject.com/ticket/30952 - KeyError: 
'_password_reset_token' during password reset. (needsinfo)
https://code.djangoproject.com/ticket/30950 - Replace __file__ with 
importlib.resources. (Someday/Maybe)
https://code.djangoproject.com/ticket/30954 - NVARCHAR2 fields are not 
using cx_Oracle.NCHAR. (wontfix)
https://code.djangoproject.com/ticket/30956 - Add support for Lower and 
Upper lookups in RangeField. (invalid)
https://code.djangoproject.com/ticket/30957 - Inconsistent slice behaviour 
on cached vs non-cached result lists in QuerySets. (wontfix)
https://code.djangoproject.com/ticket/30958 - Documentation for Cast 
function is somewhat misleading. (accepted)
https://code.djangoproject.com/ticket/30960 - manage.py command reset_db 
doesn't work with mysql.connector.django (invalid)
https://code.djangoproject.com/ticket/30959 - QuerySet.iterator() returns 
no result although QuerySet.count() is a positive number. (worksforme)
https://code.djangoproject.com/ticket/30965 - Error coming in terminal 
without any bug in code. (duplicate)
https://code.djangoproject.com/ticket/30967 - Test suite fails on Postgres 
12 (accepted)

*Reviewed/committed:*
https://github.com/django/django/pull/12002 - Refs #27808 -- Added test for 
saving nested ArrayField with nullable base field.
https://github.com/django/django/pull/11999 - Fixed #30931 -- Restored 
ability to override Model.get_FIELD_display().
https://github.com/django/django/pull/12012 - Refs #30116 -- Simplified 
stdout/stderr decoding with subprocess.run()'s encoding argument.
https://github.com/django/django/pull/12003 - Refs #13312 -- Simplified 
handling of nulls ordering on MySQL.
https://github.com/django/django/pull/11845 - Added Uzbek language.
https://github.com/django/django/pull/11274 - Fixed #30947 -- Changed 
tuples to lists in model Meta options in django.contrib modules.
https://github.com/django/django/pull/11930 - Fixed #30095 -- Fixed system 
check for RangeField/ArrayField.choices with lists and tuples.
https://github.com/django/django/pull/11984 - Refs #30923 -- Fixed an 
example of rendering templates in contrib.sites docs.
https://github.com/django/django/pull/12018 - Fixed #30928 -- Clarified 
MySQL/MariaDB support of QuerySet.select_for_update() options.
https://github.com/django/django/pull/12025 - Refs #30183 -- Doc'd dropping 
support for sqlparse < 0.2.2.
https://github.com/django/django/pull/12016 - Fixed #15742 -- Fixed an 
example of collecting selected objects in ModelAdmin.actions docs.
https://github.com/django/django/pull/11998 - Fixed #30865 -- Doc'd that 
not all DATABASES['OPTIONS'] are passed to command-line client.
https://github.com/django/django/pull/12004 - Fixed #30943 -- Added 
BloomIndex to django.contrib.postgres.
https://github.com/django/django/pull/12039 - Fixed #30961 -- Fixed spaces 
in columns list SQL generated for indexes.
https://github.com/django/django/pull/12047 - Fixed #30955 -- Doc'd that 
only concrete base models are stored in historical models bases.
https://github.com/django/django/pull/12040 - Fixed #24858 -- Added support 
for get_FOO_display() to ArrayField and RangeFields.
https://github.com/django/django/pull/12013 - Fixed #30948 -- Changed 
packaging to use setuptools declarative config in setup.cfg.

*Reviewed:*
https://github.com/django/django/pull/12029 - Doc'd archiving historical 
branches as git tags.

Best regards,
Mariusz

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ad360cdf-59c4-4ab2-a0e6-567947bf2480%40googlegroups.com.

Re: app_get_config(app_label).path as only way to get an app's path

[Aymeric Augustin]

Hello Christian,

>  if there are more than one packages with the same label?

Two apps cannot have the same label. One of them must be relabeled as described 
in 
https://docs.djangoproject.com/en/2.2/ref/applications/#django.apps.AppConfig.label
 
.

If a pluggable app wants to access its own app config even if it was relabeled, 
there's no direct API to do so, but it's a one-liner:

from django.apps import apps
app_name = "gdaps.frontend"
app_config = [ac for ac in apps.get_app_configs() if ac.name == app_name][0]

This is pretty much how apps.is_installed(app_name) is implemented. There isn't 
a more efficient way to do this with the current implementation of 
django.apps.Apps.

Perhaps the API of django.apps.Apps could be improved to facilitate such use 
cases. At first sight, there are several options to consider:

- provide an apps.get_app_label(app_name) function that would do the 
translation from app_name to app_label
- accept either an app_label (e.g. "admin") or an app_name (e.g. 
"django.contrib.admin") in APIs that currently only accept an app_label
- etc.

It's been five years since Django 1.7 was released with new app registry. 
During this time, I haven't seen app_label conflicts or relabeling causing big 
problems in practice. (The only vaguely related case I've ever seen was someone 
who copy-pasted an app under a different name. This changed both the app_label 
and the app_name, so even relying on the app_name would fail in that case.)

I'd rather keep things simple here.

Best regards,

-- 
Aymeric.


> On 10 Nov 2019, at 22:12, Christian González  
> wrote:
> 
> Hi all,
> 
> I recently found a problem - maybe I didn't get everything, but the docs
> say that, if you want to get an app's path, you should use
> get_app_config(app_label).path.
> 
> Now, passing the app_label is handy if you have few packages installed,
> but it comes to name clashes if there are multiple packages with the
> same label (but different names).
> 
> I happen to start a bigger project, and there are some packages
> installed like "gdaps.frontend". Maybe one of my plugins later will be
> named "medux.frontend". These two have a different name, but the same label.
> 
> Ok, I can simply do a
> 
> from medux import frontend
> do_something_with(os.path.dirname(frontend.__file__))
> 
> But AppConfig.get_app_config() exactly should exist because I should NOT
> do that.
> 
> How do I get the path of an app in a deterministic way, if there are
> more than one packages with the same label? Is this a bug?
> 
> Thanks,
> 
> Christian
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/c8e6e354-7d02-835e-cd62-5d38102bd374%40nerdocs.at.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/BE8FAA8F-BE28-4DDB-B36C-3CD9C5DC6164%40polytechnique.org.

Jobs available

[Jani Tiainen]

Hi everyone.

Company I work for is looking for several full stack developers. Django,
GIS, Oracle and Postgres are some of the tools we're working with.

Work is located in Joensuu, Finland (no remote possibility). We can help
with relocation if necessary, even outside EU.

Open applications can be sent to care...@keypro.fi

-- 
Jani Tiainen
Team Lead / Utilities networks

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91oc-RFcRcfMo%3D3jyzBP13dEkdG6Nn5dwygfXKtxrx%2BVicw%40mail.gmail.com.

Re: app_get_config(app_label).path as only way to get an app's path

[Christian González]

>  if there are more than one packages with the same label?
>
> Two apps cannot have the same label. One of them must be relabeled as
> described
> in 
> https://docs.djangoproject.com/en/2.2/ref/applications/#django.apps.AppConfig.label.

OMG. Are in great advantage - those who can read.

>
> If a pluggable app wants to access its own app config even if it was
> relabeled, there's no direct API to do so, but it's a one-liner:
>
> from django.apps import apps
> app_name = "gdaps.frontend"
> app_config = [ac for ac in apps.get_app_configs() if ac.name ==
> app_name][0]
>
> This is pretty much how apps.is_installed(app_name) is implemented.
> There isn't a more efficient way to do this with the current
> implementation of django.apps.Apps.
>
> Perhaps the API of django.apps.Apps could be improved to facilitate
> such use cases. At first sight, there are several options to consider:
>
> - provide an apps.get_app_label(app_name) function that would do the
> translation from app_name to app_label
> - accept either an app_label (e.g. "admin") or an app_name (e.g.
> "django.contrib.admin") in APIs that currently only accept an app_label
> - etc.
>
> It's been five years since Django 1.7 was released with new app
> registry. During this time, I haven't seen app_label conflicts or
> relabeling causing big problems in practice. (The only vaguely related
> case I've ever seen was someone who copy-pasted an app under a
> different name. This changed both the app_label and the app_name, so
> even relying on the app_name would fail in that case.)
>
> I'd rather keep things simple here.
>
Yes, understood. Not a big problem here. From a novice POV, I dumbly
expected apps.get_app_config() to find the app when given a dotted name.
So IMHO this would be a good approach.

Apps.get_apps_config() itself does a search for the name, and returns a
message to the user ATM:

try:
return self.app_configs[app_label]
except KeyError:
message = "No installed app with label '%s'." % app_label
for app_config in self.get_app_configs():
if app_config.name == app_label:
message += " Did you mean '%s'?" % app_config.label
break

This could be a return statement too.

Just my 2c.

Christian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/145544f6-9abd-c47c-b5c4-79fbf2ab0214%40nerdocs.at.


pEpkey.asc
Description: application/pgp-keys