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 django-registration" works fine for me right now. Why
not encourage people to use standard Python practices for packaging
and distribution?
> o either globally to Python packages -- *but under django namespace!
> *
> o or locally into a concrete project
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.
> * provide app dependency handling like setuptools does for
> o python package dependencies (identical to setuptools 'depends')
> o Django app dependencies (e.g. 'django_app_depends')
Or just, you know, use setuptools.
> * bundle the install tool either as a command for manage.py or a
> separate utility in bin
Or just, you know, install setuptools.
> * create the solution so that it can be adopted by other projects by
> clearly decoupling Django-specific functionality (i.e. engage more
> brainpower and devs)
Or just use the existing packaging and distribution tools Python already has.
Have I made my point clear enough yet?
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
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).
So, if TurboGears hasn't rewritten setuptools, I think there's
probably a reason. They aren't idiots, and they're much better at this
packaging and dependency stuff than we are.
>> o either globally to Python packages -- *but under django namespace!
>> *
>> o or locally into a concrete project
>
> 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 a discussion about namespace packages [1]
with Mark Ramm at PyCon, and hist short answer was "don't do it, it
isn't worth it". Seeing as he's the maintainer of TurboGears and
probably knows setuptools about as well as anyone, I'd tend to trust
him on that one. I understand the appeal, but the consequences aren't
worth it.
Joseph
[1] http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages
regards
Steve
[PSF chairman]
+1 on just packaging stuff as eggs, and being able to easy_install
them. Works great with my buildout infrastructure for managing Django
builds too. I wouldn't worry about putting stuff that's not useful
outside a Django context up; that's exactly what the categories system
is for. There's plenty of Zope stuff there, for example, and I
personally haven't seen any complaints. Maybe I just missed them.
On the namespace package front, I'd be wary; I started trying to use
them, but a client of mine on Windows has experienced problems using
them in Django (in places where some __import__ magic is done). I'll
raise a ticket when I get down to a minimal example.
Cheers,
Dan
--
Dan Fairs <dan....@gmail.com> | http://www.stereoplex.com/
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
feature:
grouping packages, trove doesn't really cut it.
+1 for PyPI usage.
Ludvig "toxik" Ericson
ludvig....@gmail.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkjIBwUACgkQXnZ94Kd6KaehKwCePlVLpBQ/gKuRKIMSMeeKuwXt
dfYAnROOUsS0gEmGpyxJ5X0OVOAgLHaG
=kRxg
-----END PGP SIGNATURE-----
At some point the Django app you're trying to installed has to go
somewhere. If it doesn't go in global or user's local, where do you
want it to go?
With virtualenv you can (and I would encourage that you) have an env
for each Django project, so any installing you do is only 'cluttering'
that project, and at that point it isn't even 'clutter'.
Brett
> 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 policy is needed:
> * designate a global namespace where all apps should live (e.g.
> django.apps.mycompany.fooapp or just django.apps.fooapp)
> * find a way for avoiding name collisions there (mycompany would deal
> with that)
> * document all the above and the steps and requirements for creating
> and publishing a reusable app.
Although this is a shameless plug, I'd like to point to a small helper
app that is able to find resuable Django apps that are packaged as egg
files. It's independent from the PYTHONPATH and hooks into the
INSTALLED_APPS setting to automatically find every Django app that has
a so called entry point, a pretty nice feature of setuptools to find
components/plugins/pluggables [1]. It also works well with virtualenv.
For more information head over to http://code.google.com/p/django-reusableapps/
and start making eggs.
Cheers,
Jannis
1: http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-of-services-and-plugins
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 five hour period, of over 3000
subscribed to the list.
I know you said this was for 2.0, and, if you really believe that's the
case, you have to really ensure that premature conclusions aren't drawn.
Regards,
Malcolm
On Wed, Sep 10, 2008 at 4:31 PM, mrts <mr...@mrts.pri.ee> 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 hacking
> o find a way to expose media
> o handle all issues outlined in #3591
>
I'd say that having CheeShop the only really important thing (my POV)
would be giving developers a few pointers on how to make their apps
more decoupled, i.e:
* Your app templates should all {% extends %} a base.html which is
the "standard" name of the base template.
* Your should work on the content, content-related, and
content-extra blocks to provide content in your example/live templates
* Your URL's should always use named urls (atleast on those meant
to be used by users).
etc. In brief, that kind of things that make an app "plug&play" or
"jumper-based" :)
Now blame me if such document already exists (in docs/), and such
document doesn't need to wait for 2.0 ;)
Regards,
Marc
--
http://www.marcfargas.com - will be finished someday.
>
> 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 are immensely useful and may be one of Djangos great
> selling points once they are easy to deploy and some order is enforced
> upon the current chaos.
>
I do not believe that this has anything to do with Django 2.0 or any
version of Django.
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?
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.
That doc could then be incorporated into djangoproject.com. The usual
community-driven caveats apply: let it be discussed, debated, etc. If
the major Django contributors begin using it for their own package
submissions, and the guidelines make sense, the community as a whole
will follow suit.
Somebody really is a great guy. He does a lot of great work for the
community, doesn't he :-)
If you think this document is required, why not write it? Don't wait
for permission - just write it!
Of course, if you actually sat down to write this document, you would
rapidly discover why it hasn't been written - the questions you need
to answer haven't got canonical answers yet. Are you familiar with the
Django Hotclub? This project started out to answer exactly these
questions, and they still don't have canonical answers. Pinax is an
attempt to discover best practices through empirical means, but they
don't have a complete set of answers.
Yours,
Russ Magee %-)
Matic Žgur
Look, that's exactly my point. Authorship aside, just throwing up a
platform for submitting packages accomplishes nothing without
packaging guidelines. Besides, we already have that. It's called
Google Code.
Pinax provides a model perhaps for the manner of packaging a project,
but as a whole is more cathedral than bazar. Is it the answer? I don't
know.
I don't know because I am not qualified to write such guidelines. I
have not been using Django long enough to understand all its parts
well enough, nor to propose how others should work. But I sure as hell
don't want to see yet another repository canonized before the footwork
is complete. Thus here's my vote: No.
The only proviso to that is that the existing web APIs used by distutils
and setuptools need to be retained. If they weren't, of course, it would
kind of nullify the point of using PyPi in the first place.
regards
Steve
Holy crap, Kevin, this is fantastic. Can you post this somewhere other
than the mailing list so that it'll have a permanent home?
Alternatively, do you mind if I do?
Jacob
Yeah, yeah, I know... but there's a very important mental difference
between a link to a mailing list post and a "real" web page; the
latter has a bit more gravitas, and I'd like to make sure that Kevin's
information gets read as much as possible.
Jacob
Erik
Erik
As others have pointed out, this isn't necessary and would be bad
practice. Everybody should feel free to use whatever namespace they like
to avoid clashes and so that we avoid lowering the quality of the Django
brand (as soon as somebody installs a few low-quality "packages" and
they misbehave in any way, it's going to be "Django is a pile of
rubbish" because it's all coming from the Django namespace).
> * dependencies should be handled with setuptools facilities
As an option, only. This can't be a requirement, since setuptools will
often download random stuff from the internet, doesn't support signed
packages as a rule, doesn't integrate well with existing packaging
systems such as rpm and apt (which includes the fact that it downloads
random extra stuff without asking) and doesn't make it easy to validate
the source code at a later date. In other words, it's insecure by design
and therefore inappropriate for large system installs. People might be
happy to use it on their laptops or whatever, but a lot of system
administrators should rightly feel very nervous about using setuptools.
Regards,
Malcolm
Don't tell that to my laptop and some systems I admin which have
completely parallel installation of Python 2.4 and everything else I
need to do Plone work, all managed by rpms, then. They don't like being
told that what they're doing is apparently impossible. :-)
Yes, it doesn't work trivially with virtualenv, but so what? It's not
part of the use-case of virtualenv and buildout which are targeted at an
different audience and use-case. Sandboxed development environments have
been in use for years and they work very well when you're developing.
They're also not how you deploy things to dozens of machines at once in
a very large installation. At that point you use the sandboxed
environment to build packages that work with the system they're being
installed on and which install in parallel. Not every sandbox
environment is designed to do that and that is fine.
> to dump everything into the global package space if you
> have diverse projects hosted on a single server.
>
> 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 want to
> do it ourselves, we have to accept the state of things.
Wow. You just said we should entirely ditch security because it isn't
convenient. That's exactly the attitude that has made Microsoft the
laughing stock of the professional IT community for the last 15 years.
If my original mail had said "nobody should ever use setup tools" or
anything like that, you reply might be valid. Go back and read it. I
said "optional", not "forbidden". There are multiple audiences here. If
Django ever had a hard dependency on setuptools for using third-party
packages it would make it very difficult for system administrators to
use Django because of the large level of security uncertainty and extra
overhead that comes with using it. So, again, it's fine for people who
want to to use setuptools and virtualenv and buildout and eggs and
rinky-dinky-tool-of-choice. People use things knowing that there are
always trade-offs and compromises. It's bad once policy starts being
enforced on something that is simply unusable in certain environments.
Regards,
Malcolm
I don't much like the pejorative implication of matching
"rinky-dinky-tool-of-choice" with the other listed alternative, however.
Personally I think virtualenv is a good solution to a tricky problem.
The thing that bugs me most of all is Python developers who assume that
the answer to all Python distribution problems is the assumption that a
single Python installation can support all required applications. In
this day and age it's quite practical to look at distributing the
required interpreter as a component of your application or framework.
There is no reason why your Python program and mine need have any
components in common, and increasingly less reason to enforce this
requirement to save disk space.
Having said which, Django and other frameworks don't have that luxury:
if I'm running Django on 2.4 then every app my Django installation
supports also has to run on 2.4.
regards
Steve
wow, that'd be pretty much enough!
maybe even without urls.py modification (this can cause troubles)
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
I am -1 on this, because all my reusable apps are under "dynamo.apps"
namespace :)
Really, there is no need for this. Introspecting applications is never
going to happen in django itself (atleast from what I understand of
the devs).
Eggs have an "entry point" concept, which could be used for this
purpose [1]. If apps are going to be reusable, might as well
distribute them as eggs.
Or you could just have people drop packages into a specific directory
in your project. (Pinax for e.g., has apps/)
Regards
Rajeev J Sebastian
[1] http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-of-services-and-plugins