Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #83317 > unrolled thread

Announce: PyPrimes 0.2.1a

Back to article view | Back to comp.lang.python

Contents

  Announce: PyPrimes 0.2.1a Steven D'Aprano <steve@pearwood.info> - 2015-01-08 04:35 +0000
    Re: Announce: PyPrimes 0.2.1a Ben Finney <ben+python@benfinney.id.au> - 2015-01-08 18:12 +1100
      Re: Announce: PyPrimes 0.2.1a Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-08 22:16 +1100
        Re: Announce: PyPrimes 0.2.1a Irmen de Jong <irmen.NOSPAM@xs4all.nl> - 2015-01-08 23:32 +0100
          Re: Announce: PyPrimes 0.2.1a Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-09 11:41 +1100
            Re: Announce: PyPrimes 0.2.1a Chris Angelico <rosuav@gmail.com> - 2015-01-09 11:50 +1100
              Re: Announce: PyPrimes 0.2.1a alister <alister.nospam.ware@ntlworld.com> - 2015-01-09 09:05 +0000
                Re: Announce: PyPrimes 0.2.1a Ben Finney <ben+python@benfinney.id.au> - 2015-01-09 22:01 +1100
                  Re: Announce: PyPrimes 0.2.1a alister <alister.nospam.ware@ntlworld.com> - 2015-01-09 11:42 +0000
            Where to learn current best Python packaging practices (was: Announce: PyPrimes 0.2.1a) Ben Finney <ben+python@benfinney.id.au> - 2015-01-09 12:11 +1100
              Re: Where to learn current best Python packaging practices (was: Announce: PyPrimes 0.2.1a) Rustom Mody <rustompmody@gmail.com> - 2015-01-08 17:39 -0800
              Re: Where to learn current best Python packaging practices (was: Announce: PyPrimes 0.2.1a) Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-08 17:42 -0800
                Re: Where to learn current best Python packaging practices Ben Finney <ben+python@benfinney.id.au> - 2015-01-09 13:37 +1100
        PyPI files should not change their payload (was: Announce: PyPrimes 0.2.1a) Ben Finney <ben+python@benfinney.id.au> - 2015-01-09 10:55 +1100
          Re: PyPI files should not change their payload (was: Announce: PyPrimes 0.2.1a) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-09 11:38 +1100
        Using a ChangeLog as a canonical source of package metadata (was: Announce: PyPrimes 0.2.1a) Ben Finney <ben+python@benfinney.id.au> - 2015-01-09 11:06 +1100
          Re: Using a ChangeLog as a canonical source of package metadata (was: Announce: PyPrimes 0.2.1a) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-12 05:17 +1100
            Re: Using a ChangeLog as a canonical source of package metadata Ben Finney <ben+python@benfinney.id.au> - 2015-01-12 07:21 +1100
              Re: Using a ChangeLog as a canonical source of package metadata wxjmfauth@gmail.com - 2015-01-11 12:37 -0800
                Re: Using a ChangeLog as a canonical source of package metadata Steven D'Aprano <steve@pearwood.info> - 2015-01-12 05:44 +0000
                  Re: Using a ChangeLog as a canonical source of package metadata wxjmfauth@gmail.com - 2015-01-12 05:24 -0800
                    Re: Using a ChangeLog as a canonical source of package metadata Steven D'Aprano <steve@pearwood.info> - 2015-01-13 06:59 +0000
                      Re: Using a ChangeLog as a canonical source of package metadata wxjmfauth@gmail.com - 2015-01-13 00:09 -0800
                        Re: Using a ChangeLog as a canonical source of package metadata Steven D'Aprano <steve@pearwood.info> - 2015-01-13 08:22 +0000
            Re: Using a ChangeLog as a canonical source of package metadata Ben Finney <ben+python@benfinney.id.au> - 2015-01-14 21:59 +1100
        Re: Using a ChangeLog as a canonical source of package metadata (was: Announce: PyPrimes 0.2.1a) Chris Angelico <rosuav@gmail.com> - 2015-01-09 11:16 +1100
    Re: Announce: PyPrimes 0.2.1a Christian Gollwitzer <auriocus@gmx.de> - 2015-01-08 08:27 +0100
      Re: Announce: PyPrimes 0.2.1a Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-08 22:20 +1100

Page 1 of 2  [1] 2  Next page →

#83317 — Announce: PyPrimes 0.2.1a

At long last, I am pleased to announce the latest version of PyPrimes, a 
pure Python package for working with prime numbers.

PyPrimes is compatible with Python 2 and 3, and includes multiple 
algorithms for the generating and testing of prime numbers, including the 
Sieve of Eratosthenes, Croft Spiral, Miller-Rabin and Fermat 
probabilistic tests.

https://pypi.python.org/pypi/pyprimes/


Examples
========


Generate prime numbers on demand:

py> it = pyprimes.primes()
py> next(it)
2
py> next(it)
3


Test whether numbers are prime:

py> pyprimes.is_prime(23)
True


Generate primes between an upper and lower limit:

py> import pyprimes
py> list(pyprimes.primes(11000000, 11000500))
[11000027, 11000053, 11000057, 11000081, 11000083, 11000089, 11000111,
 11000113, 11000149, 11000159, 11000179, 11000189, 11000273, 11000281,
 11000287, 11000291, 11000293, 11000299, 11000347, 11000351, 11000369,
 11000383, 11000387, 11000393, 11000399, 11000401, 11000419, 11000441,
 11000461, 11000467]


Find the previous and next primes from a given value:

py> pyprimes.prev_prime(10**9)
999999937
py> pyprimes.next_prime(999999937)
1000000007


Find the prime factorisation of small numbers:

py> import pyprimes.factors
py> pyprimes.factors.factorise(999999997)
[71, 2251, 6257]


Pyprimes also includes examples of naive and poor-quality, but popular, 
algorithms which should be avoided:

py> from pyprimes.awful import turner
py> it = turner()
py> [next(it) for i in range(20)]
[2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59,
61, 67, 71]

Study the source code of the "awful" module to see what not to do!


Performance
===========

As PyPrimes is written entirely in Python, it is not suitable for 
demanding high-performance applications, but performance can be quite 
reasonable for less-demanding applications. On a laptop with a AMD Turion
(tm) II P520 Dual-Core Processor, it takes 0.005 second to generate the 
first prime larger than 2**63, and about 10 seconds to generate the first 
one million primes. Testing whether 2**63+7 is prime takes under 0.1 
millisecond.


Installing PyPrimes
===================

You can download PyPrimes from here:

    https://pypi.python.org/pypi/pyprimes/

For Windows users, run the installer. For Linux, Mac and Unix users, 
unpack the source tar ball and follow the instructions.

You can also install using pip:

    pip install pyprimes==0.2.1a


(Note: pip may have problems downloading the right version if you don't 
specify a version number.)

Or you can access the latest development version:

    hg clone https://code.google.com/p/pyprimes/




-- 
Steve

[toc] | [next] | [standalone]

#83319

Steven D'Aprano <steve@pearwood.info> writes:

> (Note: pip may have problems downloading the right version if you
> don't specify a version number.)
>
> Or you can access the latest development version:
>
>     hg clone https://code.google.com/p/pyprimes/

The source has a ‘CHANGES.txt’ file which has no entry later than
version 0.2a. Why was the later version made, and when will the change
log be updated for that?

-- 
 \              “Ignorance more frequently begets confidence than does |
  `\           knowledge.” —Charles Darwin, _The Descent of Man_, 1871 |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#83324

Ben Finney wrote:

> Steven D'Aprano <steve@pearwood.info> writes:
> 
>> (Note: pip may have problems downloading the right version if you
>> don't specify a version number.)
>>
>> Or you can access the latest development version:
>>
>>     hg clone https://code.google.com/p/pyprimes/
> 
> The source has a ‘CHANGES.txt’ file which has no entry later than
> version 0.2a. Why was the later version made, and when will the change
> log be updated for that?
> 

Ah, I knew I forgot something!

0.2.1a was a version bump to try to work around an issue with PyPI. There
are no functional differences.

I screwed up the upload to PyPI, and it won't allow you to upload the same
version twice. (At least, I don't know of any way to do so.) So I had to
bump the version number to re-upload.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#83369

On 8-1-2015 12:16, Steven D'Aprano wrote:

> I screwed up the upload to PyPI, and it won't allow you to upload the same
> version twice. (At least, I don't know of any way to do so.) So I had to
> bump the version number to re-upload.

You can manually log into PyPI and fix the uploaded files using the web interface.

There also seems to be an issue with the version number, if I pip install pyprimes, I
get the 0.1 version. I have to tell pip to allow prerelease versions to get your new
version. I think it is because of the 'a' after the version number.


Irmen

[toc] | [prev] | [next] | [standalone]

#83377

Irmen de Jong wrote:

> On 8-1-2015 12:16, Steven D'Aprano wrote:
> 
>> I screwed up the upload to PyPI, and it won't allow you to upload the
>> same version twice. (At least, I don't know of any way to do so.) So I
>> had to bump the version number to re-upload.
> 
> You can manually log into PyPI and fix the uploaded files using the web
> interface.

Thanks.

 
> There also seems to be an issue with the version number, if I pip install
> pyprimes, I get the 0.1 version. I have to tell pip to allow prerelease
> versions to get your new version. I think it is because of the 'a' after
> the version number.

Yes, I mentioned this in my announcement here.

Is there a good tutorial to learn about pip? Everything I've seen so far
seems to be of one of two extremes, either:

"pip is awesome, just run 'pip install packagename' and it cannot fail!!!1!"

or 

"oh, pip did the wrong thing again? you can fix that by standing on one leg,
sacrificing a goat to the Great Old Dark Ones, deleting these files, or
possibly some other ones, and if the phase of the moon is exactly right it
will behave as you want..."

I know that pip is Officially The Best Thing Evar, but my experience so far
has been less than satisfactory.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#83378

On Fri, Jan 9, 2015 at 11:41 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> "oh, pip did the wrong thing again? you can fix that by standing on one leg,
> sacrificing a goat to the Great Old Dark Ones, deleting these files, or
> possibly some other ones, and if the phase of the moon is exactly right it
> will behave as you want..."

Replacing an existing package, without changing the version number,
*is* messy. It's not pip's fault that it's hard. That's like saying
"Oops, I committed this to source control and pushed it out to all
users, but there's a big file in it and I want to delete it so they
don't have to download it". Sure, that's possible, but it's not a
normal action, so you'll have to jump through some hoops to make it
all work properly.

Or have you been having this whole sacrificing a goat thing with a
normal workflow?

ChrisA

[toc] | [prev] | [next] | [standalone]

#83415

On Fri, 09 Jan 2015 11:50:26 +1100, Chris Angelico wrote:

> On Fri, Jan 9, 2015 at 11:41 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> "oh, pip did the wrong thing again? you can fix that by standing on one
>> leg,
>> sacrificing a goat to the Great Old Dark Ones, deleting these files, or
>> possibly some other ones, and if the phase of the moon is exactly right
>> it will behave as you want..."
> 
> Replacing an existing package, without changing the version number,
> *is* messy. It's not pip's fault that it's hard. That's like saying
> "Oops, I committed this to source control and pushed it out to all
> users, but there's a big file in it and I want to delete it so they
> don't have to download it". Sure, that's possible, but it's not a normal
> action, so you'll have to jump through some hoops to make it all work
> properly.
> 
> Or have you been having this whole sacrificing a goat thing with a
> normal workflow?
> 
> ChrisA

why not simply cheat & call it V 0.2.3 :-) it is not as if there is any 
regulation concerning what can & cannot constitute a minor release it is 
all at your own discretion.




-- 
Stamp out philately.

[toc] | [prev] | [next] | [standalone]

#83427

alister <alister.nospam.ware@ntlworld.com> writes:

> why not simply cheat & call it V 0.2.3 :-) it is not as if there is
> any regulation concerning what can & cannot constitute a minor release
> it is all at your own discretion.

Not a regulation, but a convention which it is good etiquette to follow
<URL:http://semver.org/>. Version strings are a communication, and
communication is only useful if conventions of meaning are more or less
reliable.

-- 
 \        “I hate it when my foot falls asleep during the day, because |
  `\            that means it's gonna be up all night.” —Steven Wright |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#83428

On Fri, 09 Jan 2015 22:01:38 +1100, Ben Finney wrote:

> alister <alister.nospam.ware@ntlworld.com> writes:
> 
>> why not simply cheat & call it V 0.2.3 :-) it is not as if there is any
>> regulation concerning what can & cannot constitute a minor release it
>> is all at your own discretion.
> 
> Not a regulation, but a convention which it is good etiquette to follow
> <URL:http://semver.org/>. Version strings are a communication, and
> communication is only useful if conventions of meaning are more or less
> reliable.

true, but this is a modification to the released code so a minor release 
change could be justified, especially so early in the development cycle

it would not do to make a habit of it though



-- 
The last time I saw him he was walking down Lover's Lane holding his own 
hand.
		-- Fred Allen

[toc] | [prev] | [next] | [standalone]

#83379 — Where to learn current best Python packaging practices (was: Announce: PyPrimes 0.2.1a)

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> Is there a good tutorial to learn about pip?

I'll answer what I think is the correct question: where to learn about
the current best Python packaging practices.

We have recently gained an official body whose explicit job is to
direct, and be opinionated about, packaging Python software: the Python
Packaging Authority <URL:https://www.pypa.io/>.

One of their many beneficial outputs is the Python Packaging User Guide
<URL:https://python-packaging-user-guide.readthedocs.org/>.

> I know that pip is Officially The Best Thing Evar, but my experience
> so far has been less than satisfactory.

For a very long time, Python packaging was in a truly awful state, and
seemed to get even worse with time. That is now reversed though (IMO),
and ‘pip’ does indeed represent the Best Thing So Far™ for Python
package installation.

That does not contradict the position that it's an ornery beast full of
hidden traps and compromises though; it just means that everything that
came before it (in Python) is worse :-)

Seriously, even those who believe they know a lot about Python packaging
will benefit greatly from learning about the sweeping improvements that
have been made in the past handful of years. Get thee to the Python
Packaging Authority resources and learn where we're at, and how far we
have to go.

-- 
 \       “You can stand tall without standing on someone. You can be a |
  `\         victor without having victims.” —Harriet Woods, 1927–2007 |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#83383 — Re: Where to learn current best Python packaging practices (was: Announce: PyPrimes 0.2.1a)

On Friday, January 9, 2015 at 6:42:18 AM UTC+5:30, Ben Finney wrote:
> Steven D'Aprano writes:
> 
> > Is there a good tutorial to learn about pip?
> 
> I'll answer what I think is the correct question: where to learn about
> the current best Python packaging practices.

In order to attain to full ISO 9000 buzzword compliance, how about calling it 
python-devops?
> 
> We have recently gained an official body whose explicit job is to
> direct, and be opinionated about, packaging Python software: the Python
> Packaging Authority <URL:https://www.pypa.io/>.
> 
> One of their many beneficial outputs is the Python Packaging User Guide
> <URL:https://python-packaging-user-guide.readthedocs.org/>.

Thanks
I need to look at that

Maybe good to also have something linking 'pure' python packaging with
debian python packaging

[toc] | [prev] | [next] | [standalone]

#83384 — Re: Where to learn current best Python packaging practices (was: Announce: PyPrimes 0.2.1a)

On Thursday, January 8, 2015 at 7:12:18 PM UTC-6, Ben Finney wrote:

> That does not contradict the position that [python
> packaging] is an ornery beast full of hidden traps and
> compromises though; it just means that everything that
> came before it (in Python) is worse

Ben, you've just proven the old truism of: 

    "When you're at the bottom, the only way you can go is up!"
    

[toc] | [prev] | [next] | [standalone]

#83393 — Re: Where to learn current best Python packaging practices

Rick Johnson <rantingrickjohnson@gmail.com> writes:

> On Thursday, January 8, 2015 at 7:12:18 PM UTC-6, Ben Finney wrote:
>
> > That does not contradict the position that [python packaging] is an
> > ornery beast full of hidden traps and compromises though; it just
> > means that everything that came before it (in Python) is worse

That's a mis-quoting of what I said. I was referring specifically to
‘pip’ there (i.e. that ‘pip’ is both an ornery beast, and that
everything which came before it in Python is worse). I did not say, and
do not claim, that for Python's packaging.

> Ben, you've just proven the old truism of: 
>     "When you're at the bottom, the only way you can go is up!"

And you've just proven the truism that it is easy to interpret someone
as supporting a position if you're willing to change what they actually
wrote.

-- 
 \         “I call him Governor Bush because that's the only political |
  `\              office he's ever held legally.” —George Carlin, 2008 |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#83373 — PyPI files should not change their payload (was: Announce: PyPrimes 0.2.1a)

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> I screwed up the upload to PyPI, and it won't allow you to upload the
> same version twice. (At least, I don't know of any way to do so.) So I
> had to bump the version number to re-upload.

There is currently a hack that can be done (I won't say what it is) to
upload a different payload with the same filename. Please don't do it.

This is widely regarded, and I agree, as a bug: once PyPI has a file of
a particular name (including the package version), that filename should
only ever refer to that same content and never anything else.

Over at ‘distutils-sig’, way back in 2014-09, a discussion reached the
consensus that the current undocumented ability to change the payload of
an existing file from PyPI is an oversight that needs to be closed
<URL:https://mail.python.org/pipermail/distutils-sig/2014-September/024890.html>,
with the Python Packaging Authority making its position known at
<URL:https://mail.python.org/pipermail/distutils-sig/2014-September/024921.html>:

    Silently changing released artefacts is actively user hostile. It
    breaks mirroring, it breaks redistribution, it breaks security
    audits, and it can even break installation for security conscious
    users that are using peep rather than pip.
    […]

    I am thoroughly *against* retaining a general capability to silently
    substitute the contents of previously released files with a
    different payload solely to handle the case of packaging errors that
    aren't otherwise severe enough to warrant bumping the version number
    […].
    
So, it seems you did the right thing in uploading different package
source content with a later version string.

The issue of remembering to update the Changelog document is another
matter, which I'll address in a different message.

-- 
 \     “Capitalism has destroyed our belief in any effective power but |
  `\      that of self interest backed by force.” —George Bernard Shaw |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#83376 — Re: PyPI files should not change their payload (was: Announce: PyPrimes 0.2.1a)

Ben Finney wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
> 
>> I screwed up the upload to PyPI, and it won't allow you to upload the
>> same version twice. (At least, I don't know of any way to do so.) So I
>> had to bump the version number to re-upload.
> 
> There is currently a hack that can be done (I won't say what it is) to
> upload a different payload with the same filename. Please don't do it.

I had thought that I screwed up the metadata, but it turns out I didn't.
When I discovered pip was picking the wrong version number, selecting a
four year old 0.1 version instead of the newly uploaded 0.2 version,
googling suggested that the problem might have been that I had not run

    python setup.py register

before the upload:

    python setup.py sdist bdist_wininst upload

and that re-uploading would fix the problem. So I ended up bumping the
version number so I could re-register and re-upload, but that didn't fix
the problem with pip. (Oh Google, why hast thou failed me???)

 
> This is widely regarded, and I agree, as a bug: once PyPI has a file of
> a particular name (including the package version), that filename should
> only ever refer to that same content and never anything else.

If "content" means source code and related program data, I agree, but we
should be able to adjust incorrect metadata without a version bump.

[...]
> The issue of remembering to update the Changelog document is another
> matter, which I'll address in a different message.

Yes please.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#83374 — Using a ChangeLog as a canonical source of package metadata (was: Announce: PyPrimes 0.2.1a)

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> Ben Finney wrote:
> > The source has a ‘CHANGES.txt’ file which has no entry later than
> > version 0.2a. Why was the later version made, and when will the
> > change log be updated for that?
>
> Ah, I knew I forgot something!

The perils of duplicate sources of information: a Changelog makes claims
about which version is latest, but the packaging metadata comes from
somewhere else.

This problem is addressed quite well, in my opinion, by the Debian
packaging tools. The tools by default read the following information:

* release version string
* maintainer name
* maintainer email address
* target suite (a conceptual “which Debian version should this go into”)

from the Changelog document, automatically. This means that the
Changelog document, as well as being directly useful to the recipient as
a text document, becomes the canonical place to record all those fields
for the packaging tools to read. No need to maintain duplicate records.


I would like Python's packaging tools to have the same capability.

This requires recording the Changelog document in a machine-parseable
format, with specified locations for each of the fields to be read for
each version.

I have recently gone through a process of converting the Changelog for a
package I maintain (‘python-daemon’) to reStructuredText [0]. This has
all the above features: machine-parseable, a well-defined way to attach
fields to a section, etc.

[0] reStructuredText: <URL:http://docutils.sourceforge.net/rst.html>

I've now produced a small Python library which knows how to transform a
reST Changelog to package metadata; and how to get that package metadata
into and out of a Python distribution with Distutils.

The result is that I will never again upload the package with a mismatch
between what the Changelog claims is the latest version, and what the
package metadata says.


This may be generally useful to others. I'm interested to know how
people would expect to use this. As an extension to Distutils? As a
third-party library? Something else?

-- 
 \      “Nullius in verba” (“Take no-one's word for it”) —motto of the |
  `\                                   Royal Society, since 1663-06-30 |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#83552 — Re: Using a ChangeLog as a canonical source of package metadata (was: Announce: PyPrimes 0.2.1a)

Ben Finney wrote:
[...]
> The perils of duplicate sources of information: a Changelog makes claims
> about which version is latest, but the packaging metadata comes from
> somewhere else.
> 
> This problem is addressed quite well, in my opinion, by the Debian
> packaging tools. The tools by default read the following information:
> 
> * release version string
> * maintainer name
> * maintainer email address
> * target suite (a conceptual “which Debian version should this go into”)
> 
> from the Changelog document, automatically. This means that the
> Changelog document, as well as being directly useful to the recipient as
> a text document, becomes the canonical place to record all those fields
> for the packaging tools to read. No need to maintain duplicate records.

A very interesting way to handle this, and one which deserves further
configuration.

I currently read this metadata from the Python code itself. The advantages
of putting the metadata into the source code include:

- the source code is the definitive source of information about itself;
- even if the user deletes the README and CHANGELOG files, they can 
  still find the metadata;
- if your application wants to report a version number (as many apps 
  do) then it is easy for them to do so.


But the disadvantages include:

- it's a bit sad to have to put such metadata into the source code;
- the risk of the changelog getting out of date.


> I would like Python's packaging tools to have the same capability.
> 
> This requires recording the Changelog document in a machine-parseable
> format, with specified locations for each of the fields to be read for
> each version.

I wonder whether it would be better to have setup.py check the CHANGELOG and
halt if it isn't up to date? 



> I have recently gone through a process of converting the Changelog for a
> package I maintain (‘python-daemon’) to reStructuredText [0]. This has
> all the above features: machine-parseable, a well-defined way to attach
> fields to a section, etc.
> 
> [0] reStructuredText: <URL:http://docutils.sourceforge.net/rst.html>
> 
> I've now produced a small Python library which knows how to transform a
> reST Changelog to package metadata; and how to get that package metadata
> into and out of a Python distribution with Distutils.

Sounds interesting. Where can we see this?

> The result is that I will never again upload the package with a mismatch
> between what the Changelog claims is the latest version, and what the
> package metadata says.
> 
> 
> This may be generally useful to others. I'm interested to know how
> people would expect to use this. As an extension to Distutils? As a
> third-party library? Something else?

Offering it as a third-party library is a good start, but perhaps you could
discuss this on the packaging mailing list and see whether they have any
interest in it?

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


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#83561 — Re: Using a ChangeLog as a canonical source of package metadata

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> I currently read this metadata from the Python code itself. The
> advantages of putting the metadata into the source code include:
>
> - the source code is the definitive source of information about itself;

The Changelog document should be in the same source tree and maintained
by the same people, so I don't count that as a difference between the
two approaches.

> - even if the user deletes the README and CHANGELOG files, they can 
>   still find the metadata;

Perhaps I didn't emphasise it, but: The approach I'm advocating (as
inspired by Debian packaging tools) has the version metadata
*canonically* recorded in the Changelog, but not *only* stored there.

The packaging tools parse the version metadata from the Changelog, then
duplicate whatever metadata is needed in various other places — such as
for programmatic access by the package's own code.

> - if your application wants to report a version number (as many apps 
>   do) then it is easy for them to do so.

The idea is to parse from the Changelog the version metadata, and record
it in Setuptools metadata. Then the ‘pkg_resources’ module of Setuptools
allows programmatic access to that metadata.

Thanks for enumerating those points, I think they are adequately
addressed by this approach.


> > I've now produced a small Python library which knows how to
> > transform a reST Changelog to package metadata; and how to get that
> > package metadata into and out of a Python distribution with
> > Distutils.
>
> Sounds interesting. Where can we see this?

It is the approach used in ‘python-daemon’ version 2. Find the source at
<URL:https://alioth.debian.org/projects/python-daemon/>. The
‘ChangeLog’, ‘setup.py’, ‘version.py’, ‘daemon/_metadata.py’ files are
the relevant ones to examine.

Since this is a new approach I'm trying, I flubbed a couple of versions:
you'll need version 2.0.1 or later (I omitted the ‘version’ module
entirely from the earlier distribution), and you'll need ‘docutils’
already installed (a future ‘python-daemon’ distribution will declare
this dependency).

I'll be interested to see how Python developers like this.

-- 
 \      “The process by which banks create money is so simple that the |
  `\     mind is repelled.” —John Kenneth Galbraith, _Money: Whence It |
_o__)                                       Came, Where It Went_, 1975 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#83565 — Re: Using a ChangeLog as a canonical source of package metadata

1) I downloaded pyprimes-0.2.1a.tar.gz
2) I extracted the relevant part, the py files, the pyprimes
subdirectory,
awful.py, compat23.py, factors.py, test.py, ..........
and put in d:\junk

Then, I cd to d:\junk

D:\junk>
D:\junk>c:\python32\python.exe
Python 3.2.5 (default, May 15 2013, 23:06:03) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit()

D:\junk>c:\python32\python.exe tests.py
Traceback (most recent call last):
  File "tests.py", line 35, in <module>
    import pyprimes
ImportError: No module named pyprimes

D:\junk>c:\python32\python.exe d:\junk\tests.py
Traceback (most recent call last):
  File "d:\junk\tests.py", line 35, in <module>
    import pyprimes
ImportError: No module named pyprimes

D:\junk>

Normally it should work.

All the software I wrote works indipendently
from the location.

[toc] | [prev] | [next] | [standalone]

#83595 — Re: Using a ChangeLog as a canonical source of package metadata

On Sun, 11 Jan 2015 12:37:03 -0800, wxjmfauth wrote:

> 1) I downloaded pyprimes-0.2.1a.tar.gz 
> 2) I extracted the relevant part,
> the py files, the pyprimes subdirectory,
> awful.py, compat23.py, factors.py, test.py, .......... and put in
> d:\junk

That is not the way packages work.

pyprimes is a package, which means it has to stay together in a single 
directory called "pyprimes", with a file called "__init__.py" inside it. 
It is not a set of independent modules.

Please read the README file, it explains the correct way to install 
pyprimes. You should use the setup.py installer script.

If you insist on manually doing this, you can copy the *entire* pyprimes 
package directory. That is, unpack the tar.gz file to something like this:


pyprimes/
+-- CHANGES.txt  
+-- LICENCE.txt
+-- MANIFEST  
+-- README.txt
+-- setup.py
+-- src/
    +-- pyprimes/
        +-- __init__.py
        +-- awful.py
        +-- factors.py
        +-- test.py
        etc.


Copy the *entire* folder pyprimes/src/pyprimes/ and move that somewhere 
into your PYTHONPATH. 

Or instead you can:

cd pyprimes/src  # ***NOT*** pyprimes/src/pyprimes !!!


and run python from there.


-- 
Steve

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web