Django-picklefield apparently not being maintained.

[Jorge C . Leitão]

Hi there.

First of all, I've just read these 
rules
 and 
I want to apologize for my behavior on this mailing list. I'm sorry for my 
behavior, specially in 
this
 thread, 
but also on 
this
 and 
this.
 
I now understood my very rude behavior, but I nevertheless would like to 
contribute, as from what I read in this list, this is a very serious 
community. 

Now, Django: I'm using 
Django-picklefield, 
but apparently it stop being maintained on github (the user was a company 
that no longer has a website). The issue is that the code, as it is, is not 
working. There are issues raised and not fixed more than a year now.

I fixed the issue on my local, like some of the 25 forks of the project on 
github.

I think this is a small project that would be nice for me to maintain, but 
I don't know the "etiquette rules" of how it works.

First, do you think it is worth? Is there any alternative that I'm not 
aware of (or as a new feat of Django core)? do you know of anyone that is 
maintaining it?

Secondly, what are the rules for doing this? I mean, can I just change its 
name and open a github rep, along with a pip version and give the 
respective credits to the creators?

Can anyone give me a small guideline on how to proceed on this regard?

Thanks for your time and patience,
Jorge

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Christopher Medrela]

1. One of my questions left unanswered on the pull request [1] (I mean this 
one
about documentation and `__str__` use.).

2. I've finished rewriting admin checks. I've renamed `admin_validation` to
`admin_checks`. I would like you to have a deep look at `fk_name` and
`exclude` checks [2] as well as `inline_formsets` tests [3] (especially 
error
messages).

2a. "applabel.modellabel[.fieldname]" is the format of error messages for 
models
and fields. How should the one for admin look like? I propose
"applabel.ModelAdminClassName".

2b. BaseModelAdmin, ModelAdmin and InlineModelAdmin classes and their checks
live in separated files. `options.py` defines these classes, but checks 
lives
in `checks.py`. We want to have these two issues separated, otherwise class
definitions would become too long. Python does not support open classes, so 
we
cannot just add some `_check_*` methods in `checks.py` to existing classes
defined in `options.py`.

The current approach is that `check` method is defined in `options.py`, but 
it
delegates to appropriate functions in `checks.py` [4]. Yes, I use functions 
--
there is no need to have validator class, because we don't need to store
anything in its instances. However, the code is really ugly. I wonder if 
there
is any better approach.

3. I've created a new ticket [#20974] about lack of mysql-specific checks.

4. I've rebased my branch against master.

On Fri, Aug 16, 2013 at 7:45 AM, Russell Keith-Magee  > wrote:
>
>> 8. I've added a new check. If you're using a `GenericRelation` but there 
>>> is no
>>> `GenericForeignKey` on the target model, an warning is raised. This 
>>> check was
>>> implemented in this commit [9]. It uses `vars` builtin function to check 
>>> if the
>>> target model has a `GenericForeignKey`. This is ugly, but I don't see a 
>>> better
>>> approach.
>>
>> [9] 
>>> https://github.com/chrismedrela/django/commit/ab65ff2b6d6346407a11a72c072e358c7b518cf9#L1R397
>>>
>> Hrm. I don't really like this, but I'm not sure I have a better option. A 
>> better approach would be to have GFKs turn up in get_fields, but it isn't 
>> your responsibility to fix the internal problems of Generic Foreign Keys. 
>> If we have to live with this, then we should at the very least document it 
>> as a FIXME, pointing at the underlying problem with _meta handling of GFKs.
>
>  
>  
> Michal Petruca just mailed the django-dev list with some discussion about 
> changes he wants to make in his own GSoC project, which drew my attention 
> to something I'd forgotten about.
>
 

Does _meta.virtual_fields -- contain the information you need? It looks 
> like it should.


5. Yes, you're right, `virtual_fields` is what I need.

6. Now I'm implementing filtering checks.

[1] https://github.com/django/django/pull/1364
[2] 
https://github.com/chrismedrela/django/blob/gsoc2013-checks/django/contrib/admin/checks.py#L673
[3] 
https://github.com/chrismedrela/django/blob/gsoc2013-checks/tests/inline_formsets/tests.py#L113
[4] 
https://github.com/chrismedrela/django/blob/gsoc2013-checks/django/contrib/admin/checks.py
[#20976] https://code.djangoproject.com/ticket/20976

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django-picklefield apparently not being maintained.

[Aymeric Augustin]

On 27 août 2013, at 15:28, Jorge C. Leitão  wrote:

> First, do you think it is worth? Is there any alternative that I'm not aware 
> of (or as a new feat of Django core)? do you know of anyone that is 
> maintaining it?

I don't know!

> Secondly, what are the rules for doing this? I mean, can I just change its 
> name and open a github rep, along with a pip version and give the respective 
> credits to the creators?

Here's how I would proceed.

1) Have a look at the license. In all cases, you should abide by the license 
and credit the original authors. Even if you end up rewriting almost entirely a 
library, you still started from what they had done, and they deserve credit for 
that.

Here, it's the BSD license, which is very permissive. (The README says MIT, but 
it seems to me that the LICENSE file contains a copy of the BSD license.) Both 
are all right anyway. You can do almost anything with the code.

2) Look at the network of forks: 
https://github.com/shrubberysoft/django-picklefield/network. If there's a 
popular fork, try to get in touch with its author and contribute to that fork. 
It's in everyone's interest that a new canonical repository emerge.

Here, Gintautas Miliauskas' fork appears interesting. Note that Simon Charette 
(a core dev of Django) chose to fork that one. Furthermore, Gintautas 
registered the project on PyPI: 
https://pypi.python.org/pypi/django-picklefield. That makes him the current 
maintainer of the project and you should attempt to cooperate with him.

3) Generally speaking, if you don't intend to make drastic changes, you can 
fork the repository and keep the name. It's under your account on GitHub anyway.

I hope this helps,

-- 
Aymeric.




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AutoField issue in SQLite3

[Russell Keith-Magee]

Hi Leonardo,

There's no magic hidden source of information about tickets - if there's
information, it's the discussion on the ticket.

Yours,
Russ Magee %-)



On Tue, Aug 27, 2013 at 10:14 AM, Leonardo Borges Avelino  wrote:

>
> Hi folks!
>
> Any news about this ticket: https://code.djangoproject.com/ticket/10164 ?
>
> I am having this issue using SQLite3 in django 1.5. The primary key is not 
> monotonic
> increasing.
>
>
> Leonardo
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Russell Keith-Magee]

Hi Chris,

On Wed, Aug 28, 2013 at 5:16 AM, Christopher Medrela <
chris.medr...@gmail.com> wrote:

> 1. One of my questions left unanswered on the pull request [1] (I mean
> this one
> about documentation and `__str__` use.).
>

I've left a comment on the pull request, I've given the same comment in a
previous message on this thread. Short version; I think there's potential
for other levels to be used.

(that said.. .I get the feeling I think I might have commented on the wrong
comment -- it wasn't completely clear from the link you provided)

2. I've finished rewriting admin checks. I've renamed `admin_validation` to
> `admin_checks`. I would like you to have a deep look at `fk_name` and
> `exclude` checks [2] as well as `inline_formsets` tests [3] (especially
> error
> messages).
>

I'm not sure I follow what you've done with the exclude and fk_name checks
here -- it looks like you've added some new checks, but I can't make out
exactly why those checks are needed.

I'm also not wild about the fact you've changed forms code along the way.

2a. "applabel.modellabel[.fieldname]" is the format of error messages for
> models
> and fields. How should the one for admin look like? I propose
> "applabel.ModelAdminClassName".
>

This sounds reasonable to me; the only other idea I could suggest would be
to include a '.admin' namespace in there, so it's clear that the error is
part of an admin registration, but I'm not convinced that's needed.


> 2b. BaseModelAdmin, ModelAdmin and InlineModelAdmin classes and their
> checks
> live in separated files. `options.py` defines these classes, but checks
> lives
> in `checks.py`. We want to have these two issues separated, otherwise class
> definitions would become too long. Python does not support open classes,
> so we
> cannot just add some `_check_*` methods in `checks.py` to existing classes
> defined in `options.py`.
>
> The current approach is that `check` method is defined in `options.py`,
> but it
> delegates to appropriate functions in `checks.py` [4]. Yes, I use
> functions --
> there is no need to have validator class, because we don't need to store
> anything in its instances. However, the code is really ugly. I wonder if
> there
> is any better approach.
>

Yes, there is. It's called object orientation and classes :-)

The existing validation code already does this fairly elegantly - the only
difference for your code is that you need to return multiple errors, not
just raise an exception. I'm not sure why you've tried to re-invent this
particular wheel.

Russ %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.