On Tue, Sep 16, 2008 at 1:57 PM, mrts <[EMAIL PROTECTED]> wrote:
> As for naming, `django.apps` is an arbitrary name, it can be
> `djangoapps` or whatnot. To avoid bikeshedding, core devs could decide
> on that.
>
> Of course, company sub-namespaces are entirely welcome, i.e.
>
> Namespace packages and packages living in a namespace are different
> things. I'd say the latter is sufficient.
There are two different name spacing related issues. One is PyPI
organisation, and one is the local one.
Assuming that deployment environments are only set up with the
applications
On Thu, Sep 18, 2008 at 2:49 AM, mengel <[EMAIL PROTECTED]> wrote:
> On Sep 16, 2:16 am, mrts <[EMAIL PROTECTED]> wrote:
>> * generally we should strive for a hassle-free experience so that
>> `easy_install django-foo` gives you an expected entry point (`from
>> django.apps import foo`) and
On Sep 16, 2:16 am, mrts <[EMAIL PROTECTED]> wrote:
> * generally we should strive for a hassle-free experience so that
> `easy_install django-foo` gives you an expected entry point (`from
> django.apps import foo`) and works-out-of-the-box feel
Just a slightly twisted thought, what if a
> > apt and rpm don't mix with project-specific packages and versioning
> > (virtualenv/buildout). It is just not feasible (or even possible if
> > something is built against django-0.96 and something else against
> > django-1.0)
>
> Don't tell that to my laptop and some systems I admin which
Malcolm Tredinnick wrote:
> On Tue, 2008-09-16 at 05:06 -0700, mrts wrote:
>
> [...]
>> setuptools is a necessary evil for the agile developer who frequently
>> tracks updates for the bits he relies upon. Hopefully it will be
>> improved (the clamor around it is ever-ongoing), but unless we
On Tue, 2008-09-16 at 05:06 -0700, mrts wrote:
> Both of these arguments are valid, but will not help to resolve the
> problem: smooth experience in distributing and using pluggable
> applications and some order in the current chaos.
>
> On Sep 16, 2:10 pm, Malcolm Tredinnick <[EMAIL
On Sep 16, 2:10 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Tue, 2008-09-16 at 00:16 -0700, mrts wrote:
> > Let me try to wrap this up:
>
> > * there seems to be a general consensus that amending setuptools to
> > create Django-specific extensions is not required
> > * a separate
Great mail !
This has to be published somewhere like Jacob is suggesting.
I'd like to react on the PyPI part:
On 15 sep, 04:52, Kevin Teague <[EMAIL PROTECTED]> wrote:
>
> PyPI
> -
>
> Everyone knows what this is (hopefully!). A small point to note is
> that it was originally called The
Martin Diers wrote:
> On Sep 13, 2008, at 7:23 PM, Russell Keith-Magee wrote:
>
>
>> On Sun, Sep 14, 2008 at 6:35 AM, Martin Diers <[EMAIL PROTECTED]> wrote:
>>
>>> The answer is community packaging guidelines. Somebody needs to write
>>> or adapt an existing doc on how to package django
On Sep 13, 2008, at 7:23 PM, Russell Keith-Magee wrote:
>
> On Sun, Sep 14, 2008 at 6:35 AM, Martin Diers <[EMAIL PROTECTED]> wrote:
>>
>> The answer is community packaging guidelines. Somebody needs to write
>> or adapt an existing doc on how to package django apps using existing
>> Python
I think it's a great idea to have a central repository of all apps.
Googlecode became an unofficial host of majority of third party apps,
so there seems to be a tendency for this kind of hosting. In my
opinion there is no need to reinvent hot water due to the fact that
Python already provides
On Sun, Sep 14, 2008 at 6:35 AM, Martin Diers <[EMAIL PROTECTED]> wrote:
>
> The answer is community packaging guidelines. Somebody needs to write
> or adapt an existing doc on how to package django apps using existing
> Python tools (which are excellent already), how to name them, etc.
Somebody
On Sep 14, 8:35 am, Martin Diers <[EMAIL PROTECTED]> wrote:
> The answer to the current package chaos is not a centralized
> repository. I do not like that idea one bit. It's too storm-
> trooperish. Who is going to decide whether a package is repository-
> worthy?
I would take the example of
On Sep 10, 2008, at 9:31 AM, mrts wrote:
>
> This is for Django 2.0.
>
> Rationale:
>
> a) useful (and less-useful) Django apps are proliferating on Google
> Code, djangoplugables.com and Django resources wiki page,
> b) apps need refactoring (#3591,
>
Hi,
On Wed, Sep 10, 2008 at 4:31 PM, mrts <[EMAIL PROTECTED]> wrote:
> Apps
> ---
> * extend them with Django-specific functionality to
> o lessen magic: explicitly specify files containing models,
> templates and admin bits, i.e. obsolete all forms of autodiscovery and
> path
On Wed, 2008-09-10 at 12:48 -0700, mrts wrote:
> I think we largely have a consensus now (unless someone speaks up) --
Huh?!
In my current timezone, the first mail in this thread arrived at 07:31
and you declared "consensus" at 12:48. A total of ten people
participated in the thread in that
I think we largely have a consensus now (unless someone speaks up) --
CheeseShop and the global (or virtualenv) package space is the way to
go for all apps when packaging rules have been documented.
If someone wants to take this further, a ticket + a documentation
patch that outlines how to
Am 10.09.2008 um 18:20 schrieb mrts:
> If setuptools remains the recommended way of packaging apps (I don't
> necessarily oppose this, but I'd like to hear other opinions; what I
> don't like is littering CheeseShop with stuff that is unusable in
> general Python context), at least a fixed
On Wed, Sep 10, 2008 at 11:20 AM, mrts <[EMAIL PROTECTED]> wrote:
> And it doesn't handle project-local installation (arguably this
> can be done with virtualenv, but that will just clutter user-specific
> "app-space" instead of the global one).
At some point the Django app you're trying to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 10, 2008, at 18:30, mrts wrote:
> as Django and Python communities are different, overflooding
> CheeseShop
> with Django apps does not serve Python community at all.
Sounds like an "issue" with PyPI at worst -- actually a potential
>>
>> Does anybody else actually do this? Last I checked, Pylons,
>> TurboGears
>> and Zope apps didn't install or need to be installed into
>> framework-specific locations. Django applications are just Python
>> modules, and that's a *strength* from where I sit.
>
> 100% with James here. I had
On Sep 10, 8:00 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> I don't see why Django can't be just as much a part of the Python
> community as, say, Zope, who frequently distribute code through PyPi. I
> don't see the advantage of fragmenting the infrastructure. That's what
> it's there for -
mrts wrote:
> On Sep 10, 7:12 pm, "Eric Holscher" <[EMAIL PROTECTED]> wrote:
>
>> your django apps. There is no reason to reinvent the wheel here, especially
>> after what Mark talked about at Djangocon (Django being considered seperate
>> from the Python community).
>>
>
> Although I
On Sep 10, 7:12 pm, "Eric Holscher" <[EMAIL PROTECTED]> wrote:
> your django apps. There is no reason to reinvent the wheel here, especially
> after what Mark talked about at Djangocon (Django being considered seperate
> from the Python community).
Although I don't know anything about the talk,
On Sep 10, 6:57 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> Have I made my point clear enough yet?
Your point is clear but is likely to bring less order to the current
chaos. And it doesn't handle project-local installation (arguably this
can be done with virtualenv, but that will just
On Wed, Sep 10, 2008 at 8:57 AM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On Wed, Sep 10, 2008 at 9:31 AM, mrts <[EMAIL PROTECTED]> wrote:
>> * create a central app index à la Cheeseshop
>
> Doesn't the Cheese Shop already exist?
>
>> * create an automated system similar to easy_install for
Haha, yea, sorry.
On Wed, Sep 10, 2008 at 11:17 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 10, 2008 at 12:12 PM, Eric Holscher <[EMAIL PROTECTED]>wrote:
>
>> Yea, I totally agree with this.
>>
>> I wrote a blog post about how to use setuptools and distutils to
>> distribute your
On Wed, Sep 10, 2008 at 12:12 PM, Eric Holscher <[EMAIL PROTECTED]>wrote:
> Yea, I totally agree with this.
>
> I wrote a blog post about how to use setuptools and distutils to distribute
> your django apps. There is no reason to reinvent the wheel here, especially
> after what Mark talked about
Yea, I totally agree with this.
I wrote a blog post about how to use setuptools and distutils to distribute
your django apps. There is no reason to reinvent the wheel here, especially
after what Mark talked about at Djangocon (Django being considered seperate
from the Django community).
I have
On Wed, Sep 10, 2008 at 9:31 AM, mrts <[EMAIL PROTECTED]> wrote:
> * create a central app index à la Cheeseshop
Doesn't the Cheese Shop already exist?
> * create an automated system similar to easy_install for installing
> apps from
> o that central repository
"easy_install
This is for Django 2.0.
Rationale:
a) useful (and less-useful) Django apps are proliferating on Google
Code, djangoplugables.com and Django resources wiki page,
b) apps need refactoring (#3591,
http://code.djangoproject.com/wiki/VersionOneFeatures#INSTALLED_APPSrefactoring
)
c) reusable apps
ally generated by MHonArc)
$DbVERSION='2.6.16+';
%ContentType=(
'1220712157 4','multipart/alternative',
'1221309484 57','multipart/alternative',
'1220712438 5','multipart/alternative',
'1220892697 21','multipart/alternative',
'1220698223 2','text/plain',
'1220805548 11','text/plain',
'1221129814
33 matches
Mail list logo
