On Tue, Sep 08, 2009 at 02:53:49PM +0200, Tarek Ziadé wrote:
> On Tue, Sep 8, 2009 at 2:32 PM, Eric Smith<e...@trueblade.com> wrote:
> > Tarek Ziadé wrote:
> >>
> >> On Tue, Sep 8, 2009 at 10:29 AM, Chris Withers<ch...@simplistix.co.uk>
> >> wrote:
> >>>
> >>> Tarek Ziadé wrote:
> >>>>
> >>>> - an extra function called "long_description", to be able to point a
> >>>> file for the long description field
> >>>
> >>> I can't comment on the others, but this is unnecessary. Why do you need
> >>> more
> >>> than:
> >>>
> >>> long_decription="some lump of text"
> >>>
> >>> or
> >>>
> >>> long_description_path ="path/relative/to/directory/containing/setup.py"
> >>>
> >>> ...with it being an error for both to be specified?
> >>>
> >>> cheers,
> >>>
> >>
> >> The practice in the community is to create the long_description field
> >> using a separate reStructuredText file
> >> and reaching it in setup.py like this for example:
> >>
> >> long_description = open('README.txt').read()
> >>
> >> Having a callable that provides this feature in the template allows
> >> writing:
> >>
> >> """
> >> [setup.cfg]
> >>
> >> long_description: {$ long_description('README.txt') $}
> >> """
> >>
> >> Thus avoiding to write anything in setup.py for that particular case.
> >> the callable could be called "read_file()" maybe, so it's clearer.
> >>
> >> long_description_path can't be added in the final PKG-INFO because
> >> we want a self-contained metadata static file that doesn't require an
> >> extra resource (like an external file)
> >>
> >> Whereas having a file path in setup.cfg.in is acceptable, as long as
> >> the resulting setup.cfg
> >> contains everything needed to get the metadata of the package without
> >> further depenencies.
> >>
> >> so if by the time setup.cfg.in is compiled, the path cannot be found,
> >> the field will have its value set to "UNKOWN" in setup.cfg
> >
> > Which all points out that it's setup.cfg that is the static metadata, and
> > that you can generate it any way you want. If you want to use m4, use m4. If
> > you want to use python, use python. If you want to have some makefile driven
> > approach, or use autoconf, or whatever, do that.
> >
> > setup.cfg should be entirely static except for some simple if-then-else
> > logic involving versions, as Tarek has described earlier. That is, it should
> > only contain logic that needs to be decided on the platform where the
> > installation is taking place. This is basically what RPM provides.
> >
> > Any other logic, in particular logic used solely for building setup.cfg,
> > should be outside the scope of this system, because you can use any tool at
> > all for it.
> >
>
> So you are suggesting that setup.cfg includes the "if/else" logic
> instead of having it
> in a "setup.cfg.in" file ?
I'm more in favour of your original idea to have setup.cfg being
completely static and have the if/else logic in setup.cfg.in.
Regards
Floris
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
