Re: [Distutils] setup.py install using pip

[Ronny Pfannschmidt]

But it still needs a change in command
A direct switch to a real pip command comes with a free implementation and zero 
additional features to maintain in setuptools

Am 3. Dezember 2015 23:01:21 MEZ, schrieb Erik Bray :
>On Thu, Dec 3, 2015 at 3:37 PM, Ronny Pfannschmidt
> wrote:
>> Lets avoid getting setuptools even more complex in that way
>
>It's not deeply complex--it's just bypassing the normal behavior of
>using easy_install.  In my example code I subclassed
>the existing command, but an easier approach would be to build it into
>setuptools.
>
>The way the 'install' command works in setuptools is to hand
>installation off to the easy_install command unless
>--single-version-externally-managed is specified (as well as
>--record).  Otherwise it hands installation off to the default
>base 'install' command of distutils.
>
>This proposal just adds a third option for what actual installer the
>'install' command should
>use.  But it's opt-in instead of forced on any package by default (as
>easy_install is forced on us by setuptools).
>
>> Putting pip-ish-ness on top of easy install is a maintenance horror
>and I don't think setuptools does has enough consistent developer
>resources to handle something like that
>
>It doesn't put anything "on top of" easy_install; it ignores
>easy_install.
>
>> Instead let's just give options to destroy the normal install command
>from setup.py so projects can phase out easy install forcefully making
>downstream require patches or pip usage
>
>That's the goal, yes.  This is just offering a transitional tool.
>
>
>Erik
>
>>
>> Am 3. Dezember 2015 21:06:06 MEZ, schrieb Erik Bray
>:
>>>Hi all,
>>>
>>>I've been on vacation for a bit in general, and on vacation from this
>>>mailing list even longer.  I'm not entirely caught up yet on the
>>>latest developments so apologies if something like this is entirely
>>>moot by now.
>>>
>>>But I have seen some discussions here and in other lists related to
>>>using pip for all installations, and phasing out the old distutils
>>>`./setup.py install` (eg. [1]).  This is not a new discussion, and
>>>there are many related discussions, for example, about changing
>>>setuptools not to default to egg installs anymore (see [2]).
>>>
>>>I'm definitely all for this in general.  Nowadays whenever I install
>a
>>>package from source I run `pip install .`  But of course there are a
>>>lot of existing tools, not to mention folk wisdom, assuming
>>>`./setup.py install`.  We also don't want to change the long-existing
>>>behavior in setuptools.
>>>
>>>I have a modest proposal for a small addition to setuptools that
>might
>>>be helpful in a transition away from using setuptools+distutils for
>>>installation.  This would be to add a `--pip` flag to setuptools'
>>>install command (or possibly straight in distutils too, but might as
>>>well start with setuptools).
>>>
>>>Therefore, running
>>>
>>>$ ./setup.py install --pip
>>>
>>>would be equivalent to running
>>>
>>>$ pip install .
>>>
>>>By extension, running
>>>
>>>$ ./setup.py install --pip --arg1 --arg2=foo
>>>
>>>would be equivalent to
>>>
>>>$ pip install --install-option="--arg1" --install-option="--arg2=foo"
>.
>>>
>>>and so on.
>>>
>>>By making `--pip` opt-in, it does not automatically break backward
>>>compatibility for users expecting `./setup.py install` to use
>>>easy_install.  However, individual users may opt into it globally by
>>>adding
>>>
>>>[install]
>>>pip = True
>>>
>>>to their .pydistutils.cfg.  Similarly, package authors who are
>>>confident that none of their users are ever going to care about egg
>>>installs (e.g. me) can add the same to their project's setup.cfg.
>>>
>>>Does something like this have any merit?  I hacked together a
>>>prototype which follows the sig line.  It's just a proof of concept,
>>>but seems to work in the most basic cases.  I'd like to add it to my
>>>own projects too, but would appreciate some peer review.
>>>
>>>Thanks,
>>>Erik
>>>
>>>
>>>
>>>[1]
>>>https://mail.scipy.org/pipermail/numpy-discussion/2015-November/074142.html
>>>[2]
>>>https://bitbucket.org/pypa/setuptools/issues/371/setuptools-and-state-of-pep-376
>>>
>>>
>>>$ cat pipinstall.py
>>>from distutils.errors import DistutilsArgError
>>>from setuptools.command.install import install as SetuptoolsInstall
>>>
>>>
>>>class PipInstall(SetuptoolsInstall):
>>>command_name = 'install'
>>>user_options = SetuptoolsInstall.user_options + [
>>>('pip', None, 'install using pip; ignored when also using '
>>>  '--single-version-externally-managed')
>>>]
>>>boolean_options = SetuptoolsInstall.boolean_options + ['pip']
>>>
>>>def initialize_options(self):
>>>SetuptoolsInstall.initialize_options(self)
>>>self.pip = False
>>>
>>>def finalize_options(self):
>>>SetuptoolsInstall.finalize_options(self)
>>>
>>>if self.single_version_externally_managed:

Re: [Distutils] namespace_package

[KP]

Yes, the https://github.com/pypa/pip/issues/3 definitely sounds like my
issue. Seems there is some concern over the nspkg.pth there as well. It
seems taht the nspkg.pth is a fine idea to replace the install of the
__init__.py, but that it just doesn't work to fully extend the locations in
which a namespace can reside.

Either way, there a few other workarounds posted there as well, I will
check them out to see if any of them are more palatable than the one I
posted here.

Thanks Lele for sending that link!

-Kevin

On Thu, Dec 3, 2015 at 3:19 AM, Lele Gaifax  wrote:

> Zvezdan Petkovic  writes:
>
> > Hi KP,
> >
> >> On Dec 2, 2015, at 7:00 PM, KP  wrote:
> >>
> >> >It looks like you are trying to find a workaround for the problem that
> perhaps is not a problem at all if you use the standard approach properly.
> >>
> >> I'm definitely _trying_ to use a standard approach...That is why I am
> here posting. Put simply this seems like a valid use case:
> >>
> >> >pip install foo.bar
> >> >pip install -e svn+http://
> >>
> >> Even if both tools have the namespace_package foo, the "foo.more" will
> not properly import.
> >>
> >> How is this going against standard approaches?
> >
> > I don’t know.
> > Without seeing the source code for these packages (which Marius already
> asked for) everything is hypothetical.
> > All I know is that I’m using namespaces successfully for over a decade
> now and never had the need to work around them.
> >
> > Show us the code.  We may be able to help better if we can try and
> reproduce.
> > Otherwise, it’s hard.
>
> It seems that KP case is either https://github.com/pypa/pip/issues/3160 or
> https://github.com/pypa/pip/issues/3, isn't it? Both come with sample code
> that demonstrate the problem.
>
> ciao, lele.
> --
> nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
> real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
> l...@metapensiero.it  | -- Fortunato Depero, 1929.
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] setup.py install using pip

[Erik Bray]

Hi all,

I've been on vacation for a bit in general, and on vacation from this
mailing list even longer.  I'm not entirely caught up yet on the
latest developments so apologies if something like this is entirely
moot by now.

But I have seen some discussions here and in other lists related to
using pip for all installations, and phasing out the old distutils
`./setup.py install` (eg. [1]).  This is not a new discussion, and
there are many related discussions, for example, about changing
setuptools not to default to egg installs anymore (see [2]).

I'm definitely all for this in general.  Nowadays whenever I install a
package from source I run `pip install .`  But of course there are a
lot of existing tools, not to mention folk wisdom, assuming
`./setup.py install`.  We also don't want to change the long-existing
behavior in setuptools.

I have a modest proposal for a small addition to setuptools that might
be helpful in a transition away from using setuptools+distutils for
installation.  This would be to add a `--pip` flag to setuptools'
install command (or possibly straight in distutils too, but might as
well start with setuptools).

Therefore, running

$ ./setup.py install --pip

would be equivalent to running

$ pip install .

By extension, running

$ ./setup.py install --pip --arg1 --arg2=foo

would be equivalent to

$ pip install --install-option="--arg1" --install-option="--arg2=foo" .

and so on.

By making `--pip` opt-in, it does not automatically break backward
compatibility for users expecting `./setup.py install` to use
easy_install.  However, individual users may opt into it globally by
adding

[install]
pip = True

to their .pydistutils.cfg.  Similarly, package authors who are
confident that none of their users are ever going to care about egg
installs (e.g. me) can add the same to their project's setup.cfg.

Does something like this have any merit?  I hacked together a
prototype which follows the sig line.  It's just a proof of concept,
but seems to work in the most basic cases.  I'd like to add it to my
own projects too, but would appreciate some peer review.

Thanks,
Erik



[1] https://mail.scipy.org/pipermail/numpy-discussion/2015-November/074142.html
[2] 
https://bitbucket.org/pypa/setuptools/issues/371/setuptools-and-state-of-pep-376


$ cat pipinstall.py
from distutils.errors import DistutilsArgError
from setuptools.command.install import install as SetuptoolsInstall


class PipInstall(SetuptoolsInstall):
command_name = 'install'
user_options = SetuptoolsInstall.user_options + [
('pip', None, 'install using pip; ignored when also using '
  '--single-version-externally-managed')
]
boolean_options = SetuptoolsInstall.boolean_options + ['pip']

def initialize_options(self):
SetuptoolsInstall.initialize_options(self)
self.pip = False

def finalize_options(self):
SetuptoolsInstall.finalize_options(self)

if self.single_version_externally_managed:
self.pip = False

if self.pip:
try:
import pip
except ImportError:
raise DistutilsArgError(
'pip must be installed in order to install with the '
'--pip option')

def run(self):
if self.pip:
import pip
opts = (['install', '--ignore-installed'] +
['--install-option="{0}"'.format(opt)
 for opt in self._get_command_line_opts()])
pip.main(opts + ['.'])
else:
SetuptoolsInstall.run(self)

def _get_command_line_opts(self):
# Generate a mapping from the attribute name associated with a
# command-line option to the name of the command-line option (including
# an = if the option takes an argument)
attr_to_opt = dict((opt[0].rstrip('=').replace('-', '_'), opt[0])
   for opt in self.user_options)

opt_dict = self.distribution.get_option_dict(self.get_command_name())
opts = []

for attr, value in opt_dict.items():
if value[0] != 'command line' or attr == 'pip':
# Only look at options passed in on the command line (ignoring
# the pip option itself)
continue

opt = attr_to_opt[attr]

if opt in self.boolean_options:
opts.append('--' + opt)
else:
opts.append('--{0}{1}'.format(opt, value[1]))

return opts

@staticmethod
def _called_from_setup(run_frame):
# A hack to work around a setuptools hack
return SetuptoolsInstall._called_from_setup(run_frame.f_back)
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] distutils.command.build_clib: How to add additional compiler flags for cl.exe?

[Erik Bray]

On Sun, Nov 29, 2015 at 10:44 AM, Kim Walisch  wrote:
> Hi,
>
> For distutils.command.build_clib the commonly used code below does not
> work for adding additional compiler flags (it works using
> distutils.command.build_ext):
>
> extra_compile_args = '-fopenmp'
>
> On Unix-like system I found a workaround which allows to specify
> additional compiler flags for distutils.command.build_clib:
>
> cflags = distutils.sysconfig.get_config_var('CFLAGS')
> distutils.sysconfig._config_vars['CFLAGS'] = cflags + " -fopenmp"
>
> Unfortunately this does not work with Microsoft's C/C++ compiler
> cl.exe.
>
> Does anybody know how I can add additional compiler flags for cl.exe
> and distutils.command.build_clib?
>
> Thanks and best regards!

Really what I think you want is a way to determine what compiler will
be used, and to add compiler arguments accordingly.  Unfortunately
distutils does not provide one easy way to determine what compiler it
will use--this is among the myriad ways it's not great for use as a
build system.

And yet there are several workarounds.  For starters you can try:

from distutils import ccompiler

compiler = ccompiler.get_default_compiler()

if compiler == 'msvc':
# Add option for MS compiler
elif compiler == 'unix':
# Add option for gcc
elif # etc

This does not actually tell you what compiler executable will be
used--for that you have to dig around more.  This is telling you the
name of the compiler class in distutils that will be used.  But if you
want to pass arguments for cl.exe, it will be 'msvc'.

This also does not guarantee which compiler will actually be used--a
user can override that via a command-line argument or setup.cfg.  To
get around that I usually use a dummy 'Distribution' object to parse
any user arguments.  This isn't perfect either, but it's almost
exactly what happens when the setup() function is called--it just
stops before actually running any of the commands:

from distutils.dist import Distribution
from distutils import ccompiler

def get_compiler():
dist = Distribution({'script_name': os.path.basename(sys.argv[0]),
'script_args': sys.argv[1:]})
dist.parse_config_files()
dist.parse_command_line()
compiler = None

for cmd in ['build', 'build_ext', 'build_clib']:
compiler = dist.command_options.get(cmd, {}).get('compiler',
('', None))[1]
if compiler is not None:
break

if compiler is None:
return ccompiler.get_default_compiler()
else:
return compiler


I'd love to know if there is a better way in general to do this myself...


Erik
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] setup.py install using pip

[Erik Bray]

On Thu, Dec 3, 2015 at 3:37 PM, Ronny Pfannschmidt
 wrote:
> Lets avoid getting setuptools even more complex in that way

It's not deeply complex--it's just bypassing the normal behavior of
using easy_install.  In my example code I subclassed
the existing command, but an easier approach would be to build it into
setuptools.

The way the 'install' command works in setuptools is to hand
installation off to the easy_install command unless
--single-version-externally-managed is specified (as well as
--record).  Otherwise it hands installation off to the default
base 'install' command of distutils.

This proposal just adds a third option for what actual installer the
'install' command should
use.  But it's opt-in instead of forced on any package by default (as
easy_install is forced on us by setuptools).

> Putting pip-ish-ness on top of easy install is a maintenance horror and I 
> don't think setuptools does has enough consistent developer resources to 
> handle something like that

It doesn't put anything "on top of" easy_install; it ignores easy_install.

> Instead let's just give options to destroy the normal install command from 
> setup.py so projects can phase out easy install forcefully making downstream 
> require patches or pip usage

That's the goal, yes.  This is just offering a transitional tool.


Erik

>
> Am 3. Dezember 2015 21:06:06 MEZ, schrieb Erik Bray :
>>Hi all,
>>
>>I've been on vacation for a bit in general, and on vacation from this
>>mailing list even longer.  I'm not entirely caught up yet on the
>>latest developments so apologies if something like this is entirely
>>moot by now.
>>
>>But I have seen some discussions here and in other lists related to
>>using pip for all installations, and phasing out the old distutils
>>`./setup.py install` (eg. [1]).  This is not a new discussion, and
>>there are many related discussions, for example, about changing
>>setuptools not to default to egg installs anymore (see [2]).
>>
>>I'm definitely all for this in general.  Nowadays whenever I install a
>>package from source I run `pip install .`  But of course there are a
>>lot of existing tools, not to mention folk wisdom, assuming
>>`./setup.py install`.  We also don't want to change the long-existing
>>behavior in setuptools.
>>
>>I have a modest proposal for a small addition to setuptools that might
>>be helpful in a transition away from using setuptools+distutils for
>>installation.  This would be to add a `--pip` flag to setuptools'
>>install command (or possibly straight in distutils too, but might as
>>well start with setuptools).
>>
>>Therefore, running
>>
>>$ ./setup.py install --pip
>>
>>would be equivalent to running
>>
>>$ pip install .
>>
>>By extension, running
>>
>>$ ./setup.py install --pip --arg1 --arg2=foo
>>
>>would be equivalent to
>>
>>$ pip install --install-option="--arg1" --install-option="--arg2=foo" .
>>
>>and so on.
>>
>>By making `--pip` opt-in, it does not automatically break backward
>>compatibility for users expecting `./setup.py install` to use
>>easy_install.  However, individual users may opt into it globally by
>>adding
>>
>>[install]
>>pip = True
>>
>>to their .pydistutils.cfg.  Similarly, package authors who are
>>confident that none of their users are ever going to care about egg
>>installs (e.g. me) can add the same to their project's setup.cfg.
>>
>>Does something like this have any merit?  I hacked together a
>>prototype which follows the sig line.  It's just a proof of concept,
>>but seems to work in the most basic cases.  I'd like to add it to my
>>own projects too, but would appreciate some peer review.
>>
>>Thanks,
>>Erik
>>
>>
>>
>>[1]
>>https://mail.scipy.org/pipermail/numpy-discussion/2015-November/074142.html
>>[2]
>>https://bitbucket.org/pypa/setuptools/issues/371/setuptools-and-state-of-pep-376
>>
>>
>>$ cat pipinstall.py
>>from distutils.errors import DistutilsArgError
>>from setuptools.command.install import install as SetuptoolsInstall
>>
>>
>>class PipInstall(SetuptoolsInstall):
>>command_name = 'install'
>>user_options = SetuptoolsInstall.user_options + [
>>('pip', None, 'install using pip; ignored when also using '
>>  '--single-version-externally-managed')
>>]
>>boolean_options = SetuptoolsInstall.boolean_options + ['pip']
>>
>>def initialize_options(self):
>>SetuptoolsInstall.initialize_options(self)
>>self.pip = False
>>
>>def finalize_options(self):
>>SetuptoolsInstall.finalize_options(self)
>>
>>if self.single_version_externally_managed:
>>self.pip = False
>>
>>if self.pip:
>>try:
>>import pip
>>except ImportError:
>>raise DistutilsArgError(
>>  'pip must be installed in order to install with the '
>>'--pip option')
>>
>>def run(self):
>>if self.pip:
>>import pip

Re: [Distutils] setup.py install using pip

[Ronny Pfannschmidt]

Lets avoid getting setuptools even more complex in that way 

Putting pip-ish-ness on top of easy install is a maintenance horror and I don't 
think setuptools does has enough consistent developer resources to handle 
something like that

Instead let's just give options to destroy the normal install command from 
setup.py so projects can phase out easy install forcefully making downstream 
require patches or pip usage



Am 3. Dezember 2015 21:06:06 MEZ, schrieb Erik Bray :
>Hi all,
>
>I've been on vacation for a bit in general, and on vacation from this
>mailing list even longer.  I'm not entirely caught up yet on the
>latest developments so apologies if something like this is entirely
>moot by now.
>
>But I have seen some discussions here and in other lists related to
>using pip for all installations, and phasing out the old distutils
>`./setup.py install` (eg. [1]).  This is not a new discussion, and
>there are many related discussions, for example, about changing
>setuptools not to default to egg installs anymore (see [2]).
>
>I'm definitely all for this in general.  Nowadays whenever I install a
>package from source I run `pip install .`  But of course there are a
>lot of existing tools, not to mention folk wisdom, assuming
>`./setup.py install`.  We also don't want to change the long-existing
>behavior in setuptools.
>
>I have a modest proposal for a small addition to setuptools that might
>be helpful in a transition away from using setuptools+distutils for
>installation.  This would be to add a `--pip` flag to setuptools'
>install command (or possibly straight in distutils too, but might as
>well start with setuptools).
>
>Therefore, running
>
>$ ./setup.py install --pip
>
>would be equivalent to running
>
>$ pip install .
>
>By extension, running
>
>$ ./setup.py install --pip --arg1 --arg2=foo
>
>would be equivalent to
>
>$ pip install --install-option="--arg1" --install-option="--arg2=foo" .
>
>and so on.
>
>By making `--pip` opt-in, it does not automatically break backward
>compatibility for users expecting `./setup.py install` to use
>easy_install.  However, individual users may opt into it globally by
>adding
>
>[install]
>pip = True
>
>to their .pydistutils.cfg.  Similarly, package authors who are
>confident that none of their users are ever going to care about egg
>installs (e.g. me) can add the same to their project's setup.cfg.
>
>Does something like this have any merit?  I hacked together a
>prototype which follows the sig line.  It's just a proof of concept,
>but seems to work in the most basic cases.  I'd like to add it to my
>own projects too, but would appreciate some peer review.
>
>Thanks,
>Erik
>
>
>
>[1]
>https://mail.scipy.org/pipermail/numpy-discussion/2015-November/074142.html
>[2]
>https://bitbucket.org/pypa/setuptools/issues/371/setuptools-and-state-of-pep-376
>
>
>$ cat pipinstall.py
>from distutils.errors import DistutilsArgError
>from setuptools.command.install import install as SetuptoolsInstall
>
>
>class PipInstall(SetuptoolsInstall):
>command_name = 'install'
>user_options = SetuptoolsInstall.user_options + [
>('pip', None, 'install using pip; ignored when also using '
>  '--single-version-externally-managed')
>]
>boolean_options = SetuptoolsInstall.boolean_options + ['pip']
>
>def initialize_options(self):
>SetuptoolsInstall.initialize_options(self)
>self.pip = False
>
>def finalize_options(self):
>SetuptoolsInstall.finalize_options(self)
>
>if self.single_version_externally_managed:
>self.pip = False
>
>if self.pip:
>try:
>import pip
>except ImportError:
>raise DistutilsArgError(
>  'pip must be installed in order to install with the '
>'--pip option')
>
>def run(self):
>if self.pip:
>import pip
>opts = (['install', '--ignore-installed'] +
>['--install-option="{0}"'.format(opt)
> for opt in self._get_command_line_opts()])
>pip.main(opts + ['.'])
>else:
>SetuptoolsInstall.run(self)
>
>def _get_command_line_opts(self):
># Generate a mapping from the attribute name associated with a
># command-line option to the name of the command-line option (including
># an = if the option takes an argument)
>  attr_to_opt = dict((opt[0].rstrip('=').replace('-', '_'), opt[0])
>   for opt in self.user_options)
>
>  opt_dict = self.distribution.get_option_dict(self.get_command_name())
>opts = []
>
>for attr, value in opt_dict.items():
>if value[0] != 'command line' or attr == 'pip':
> # Only look at options passed in on the command line (ignoring
># the pip option itself)
>continue
>
>opt = attr_to_opt[attr]
>
>if opt in 

Re: [Distutils] Versioned trove classifiers for Django

[Maurits van Rees]

Could you add Plone 5.1 too?  It may still take half a year or more 
before we release this, but we are starting to think about what we want 
to put in there.

So this one:

Framework :: Plone :: 5.1

Thanks,

Maurits

Op 02/12/15 om 01:54 schreef Richard Jones:

At the moment it's a manual poke, but I have done this thing right now.

On 2 December 2015 at 10:46, James Bennett > wrote:

Reviving this old thread because today is Django 1.9's release date
and I'm unsure of the process for keeping up with new-released
versions in trove classifiers. Do we need to manually poke someone
each time (as with today, when "Framework :: Django :: 1.9" becomes
a thing), or is there a way to automate it?

___
Distutils-SIG maillist  - Distutils-SIG@python.org

https://mail.python.org/mailman/listinfo/distutils-sig




___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig




--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Versioned trove classifiers for Django

[Richard Jones]

I prefer not to add classifiers unless they're actually going to be used.
Half a year could turn into a year :-)

On 4 December 2015 at 08:22, Maurits van Rees 
wrote:

> Could you add Plone 5.1 too?  It may still take half a year or more before
> we release this, but we are starting to think about what we want to put in
> there.
> So this one:
>
> Framework :: Plone :: 5.1
>
> Thanks,
>
> Maurits
>
> Op 02/12/15 om 01:54 schreef Richard Jones:
>
>> At the moment it's a manual poke, but I have done this thing right now.
>>
>> On 2 December 2015 at 10:46, James Bennett > > wrote:
>>
>> Reviving this old thread because today is Django 1.9's release date
>> and I'm unsure of the process for keeping up with new-released
>> versions in trove classifiers. Do we need to manually poke someone
>> each time (as with today, when "Framework :: Django :: 1.9" becomes
>> a thing), or is there a way to automate it?
>>
>> ___
>> Distutils-SIG maillist  - Distutils-SIG@python.org
>> 
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>>
>>
>>
>> ___
>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>>
>
> --
> Maurits van Rees: http://maurits.vanrees.org/
> Zest Software: http://zestsoftware.nl
>
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Versioned trove classifiers for Django

[Maurits van Rees]

Fair enough. :-)

See you in six or more months. ;-)

Maurits

Op 04/12/15 om 00:53 schreef Richard Jones:

I prefer not to add classifiers unless they're actually going to be
used. Half a year could turn into a year :-)

On 4 December 2015 at 08:22, Maurits van Rees
> wrote:

Could you add Plone 5.1 too?  It may still take half a year or more
before we release this, but we are starting to think about what we
want to put in there.
So this one:

Framework :: Plone :: 5.1



--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig