Re: [Distutils] Deprecating/Removing OpenID/Google login support for PyPI

[Matthias Bussonnier]

> * Very few people actually are using OpenID or Google logins as it is. In
one month we had ~15k logins using the web form, ~5k using basic auth, and
62 using Google and 7 using OpenID. This is a several orders of magnitude
difference.

Not opposing to open-id/Google-ID removal, but I would love to
login-with-google, though because I already have an account (and can't
associate my google account with the PyPI one) I'm not using login with
google. Also it did not work for as long as I can remember. So the low
number of people actually _using_ it might not reflect people who would
like to use it. Maybe look at the number of people trying and failing ?

-- 
M

On 12 January 2018 at 21:51, Donald Stufft  wrote:

> As folks are likely aware, legacy PyPI currently supports logging in using
> OpenID and Google Auth while Warehouse does not. After much deliberation,
> I’ve decided that Warehouse will not be implementing OpenID or Google
> logins, and once we shutdown legacy PyPI, OpenID/ and Google logins to PyPI
> will no longer be possible.
>
> This decision was made for a few reasons:
>
> * Very few people actually are using OpenID or Google logins as it is. In
> one month we had ~15k logins using the web form, ~5k using basic auth, and
> 62 using Google and 7 using OpenID. This is a several orders of magnitude
> difference.
> * Regardless of how you log into PyPI (Password or Google/OpenID) you’re
> required to have a password added to your account to actually upload
> anything to PyPI. This negates much of the benefit of a federated
> authentication for PyPI as it stands.
> * Keeping these requires ongoing maintenance to deal with any changes in
> the specification or to update as Google deprecates/changes things.
> * Adding support for them to Warehouse requires additional work that could
> better be used elsewhere, where it would have a higher impact.
>
> - Donald
> ___
> 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] Immutability of Release Metadata in Warehouse

[Matthias Bussonnier]

I support the goal of making metadata match files as well. One alternative
is have the ability to "yank" a package. Make it still available, but
installable only when pinned explicitly. I believe that's what Rust does.
-- 
M

On Dec 19, 2017 22:21, "Thomas Kluyver" <tho...@kluyver.me.uk> wrote:

On Tue, Dec 19, 2017, at 9:10 PM, Matthias Bussonnier wrote:

One case I could see is the use of the requires_python metadata. It was not
included in the recent release of Django 2.0 (which is py 3 only) and
making a new release will be useless as pip on py2 will still see Django
2.0.0 as Py 2 compatible download it and crash.


Something similar happened to pytest - version 3.3 dropped support for
Python 3.3 (the numbering is a coincidence,  AFAIK). The requires-python
metadata was set in the package, but the package was published via a devpi
server, which didn't preserve that metadata correctly to send to PyPI. So
now 'pip install pytest' on Python 3.3 downloads the new version and fails,
rather than downloading an older, compatible version. The only way the
project can fix this is to delete the releases with incorrect metadata.

I support the larger goal of making metadata on PyPI match the metadata in
the package, however.

Thomas



___
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] Immutability of Release Metadata in Warehouse

[Matthias Bussonnier]

One case I could see is the use of the requires_python metadata. It was not
included in the recent release of Django 2.0 (which is py 3 only) and
making a new release will be useless as pip on py2 will still see Django
2.0.0 as Py 2 compatible download it and crash.

I'm going to assume with time more packages will be affected even with
minor version of Python.

-- 
M


On Dec 19, 2017 21:17, "Sumana Harihareswara"  wrote:

For those who want to track the relevant GitHub issues:

* supporting Markdown https://github.com/pypa/warehouse/issues/869
* staged releases https://github.com/pypa/warehouse/issues/726
* advising packagers to run `python setup.py check -r -s`
https://github.com/pypa/python-packaging-user-guide/issues/210

--
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc
___
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] Reproducible builds (Sdist)

[Matthias Bussonnier]

Hi all,

On Fri, Sep 29, 2017 at 12:04 PM, Jakub Wilk <jw...@jwilk.net> wrote:
> It not enough to normalize timestamps. You need to normalize permissions and
> ownership, too.
>
> (I'm using https://pypi.python.org/pypi/distutils644 for normalizing
> permissions/ownership in my own packages.)
>
Thanks Jakub this will be helpful for me;

> Yeah, I don't believe distutils honors SOURCE_DATE_EPOCH at the moment.
>
>> Second; is there a convention to store the SDE value ?
>
> In the changelog.

I'll consider that as well;


On Sun, Oct 1, 2017 at 10:31 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 30 September 2017 at 06:02, Thomas Kluyver <tho...@kluyver.me.uk> wrote:
>> On Fri, Sep 29, 2017, at 07:16 PM, Matthias Bussonnier wrote:
>
> For distro level reproducible build purposes, we typically treat the
> published tarball *as* the original sources, and don't really worry
> about the question of "Can we reproduce that tarball, from that VCS
> tree?".

Thanks for the detail explanation Nick, even if this was not the
original goal of SDE,
I would still like to have it reproducible build of sdist even if my package
does not have source generation like Cython;  I'll embed the timestamp in the
commit for now;  and see if I can also extract the timestamp from the
commit log.
AFAICT it's `git log -1 --pretty=format:%ct` if it's of interest to anyone.

My interest in this is to have CI to build the sdist, and make sure independant
machines can get the same artifact in order to have a potentially distributed
agreement on what the sdist is.

Is there any plan (or would it be accepted), to try to upstream patches like
distutils644 Jakub linked to ?

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

Re: [Distutils] Reproducible builds (Sdist)

[Matthias Bussonnier]

> Does it make sense to add a new optional metadata field to store the
> value of SOURCE_DATE_EPOCH if it's set when a distribution is built? I
> guess it could cause problems if unpacking & repacking a tarball means
> that its metadata is no longer accurate, though.

That make sens – and that would be useful, but then that mean you need
to have the sdist to reproduce the sdist...
I was more thinking of a location in the source-tree/commit; for
example in pyproject.toml's tool section.
So if I give you only that you can tell me "When I build the sdist I
get this sha256", and I can do the same independently.

-- 
M

On Fri, Sep 29, 2017 at 1:02 PM, Thomas Kluyver <tho...@kluyver.me.uk> wrote:
> On Fri, Sep 29, 2017, at 07:16 PM, Matthias Bussonnier wrote:
>> Second; is there a convention to store the SDE value ? I don't seem to
>> be able to find one. It is nice to have reproducible build; but if
>> it's a pain for reproducers to find the SDE value that highly decrease
>> the value of SDE build.
>
> Does it make sense to add a new optional metadata field to store the
> value of SOURCE_DATE_EPOCH if it's set when a distribution is built? I
> guess it could cause problems if unpacking & repacking a tarball means
> that its metadata is no longer accurate, though.
>
> Thomas
> ___
> 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] Reproducible builds (Sdist)

[Matthias Bussonnier]

Hello there,

I'm going to ask questions about Reproducible Builds, a previous
thread have been started in March[1], but does not cover some of the
questions I have.

In particular I'm interested in the reproducible build of an _sdist_.
That is to say the process of going from a given commit to the
corresponding TGZ file. It is my understanding that setting
SOURCE_DATE_EPOCH (SDE for short) should allow a reproducible building
of an Sdist;
And by reproducible I mean that the tgz itself is the same byte for
byte;  (the unpacked-content being the same is a weaker form I'm less
interested in).
Is this assumption correct?

In particular I cannot seem to be able to do that without unpacking
and repacking the tgz myself; because the copy_tree-taring and the
gziping by default embed the current timestamp of when these functions
were ran. Am I missing something ?

Second; is there a convention to store the SDE value ? I don't seem to
be able to find one. It is nice to have reproducible build; but if
it's a pain for reproducers to find the SDE value that highly decrease
the value of SDE build.

Also congrats for pep 517 and thanks for everyone who participated;

Thanks
-- 
Matthias

1: https://mail.python.org/pipermail/distutils-sig/2017-March/030284.html
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] A possible refactor/streamlining of PEP 517

[Matthias Bussonnier]

On Thu, Jul 6, 2017 at 10:57 AM, Thomas Kluyver  wrote:
> Thank-you all for the discussion and the attempts to accommodate flit,
> but I'll bow out now. It's become clear that the way flit approaches
> packaging is fundamentally incompatible with the priorities other people
> have for the ecosystem. Namely, I see sdists as archival artifacts to be
> made approximately once per release, but the general trend is to make
> them a key part of the build pipeline.

Thanks Thomas for all the effort you've put into flit, the reviving of
this pep, and the draft implementation you made. I'm sad to see you
move away from this discussion, but I can understand it can be
exhausting with the large number of exchanges and being twice almost
done.

>
> Making a guerilla tool with no concern for integration was fun. It
> became frustrating as people began to use it and expected it to play
> well with other tools, so I jumped on PEP 517 as a way to bring it into
> the fold. That didn't work out, and a tool that doesn't play well with
> pip can only be an attractive nuisance at best, even if it technically
> complies with the relevant specs.
>
> Flit is therefore deprecated, and I recommend anyone using it migrate
> back to setup.py packaging.

This make me sad as well, honestly flit is the only tool I can
remember how to use without having to lookup information online and
was really pleasant to use. As long as it still work as is I might
still continue publishing packages with it – even if its wheel only.
It would have been nice to have some integration with pip though
without too much complexity for you.

I join Ralf in both his comments, and also hope the PEP will get back
to a state were you'll consider un-deprecating flit and reintegrating
your work.

Thanks,
-- 
Matthias



>
> Best wishes,
> Thomas
> ___
> 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] Malicious packages on PyPI

[Matthias Bussonnier]

On Thu, Jun 1, 2017 at 3:20 PM, Jannis Gebauer  wrote:
> This makes me remember
> https://hackernoon.com/building-a-botnet-on-pypi-be1ad280b8d6 on a related
> note.
>
>
> Yep, that’s basically the same thing. Instead of using package names of
> builtins, the attacker is using a combination of popular apt/yum packages
> with a mix of package names with typos.
>
> During development, it’s not uncommon to make mistakes like:
>
> pip install requirements.txt (forgot the -r)
> pip install requestd (typo)
> pip install tkinter (not registered)
>
> Or to use the wrong package manager (apt-get install python-dev vs. pip
> install python-dev).
>
> I wonder if it would make sense to build some kind of blacklist for this.
> According to the blog post there were close to 10k installs over a period of
> just three days. I believe Debian is running some kind of popularity contest
> for their packages which could be used to identify problematic packages.
> This will be a lot of manual work, but I’d work on a list like this.
>
>

Does PyPA have a list of the most 404'ed requests for PyPI ? As pip
install `doesnotexists` will get pypi's
`pypi.python.org/simple/doesnotexist/` we can likely get a quick idea
of what is currently unregistered and could potentially be dangerous.
That seem more efficient that trying to guess.
-- 
M
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] reproducible builds

[Matthias Bussonnier]

On Fri, Mar 17, 2017 at 10:19 AM, Robin Becker  wrote:
> An issue has been raised for reportlab to support a specific environment
> variable namely SOURCE_DATE_EPOCH. The intent is that we should get our time
> from this variable rather than time.localtime(time.time()) so that produced
> documents are more invariant.
>
> First off is this a reasonable request? The variable is defined by debian
> here https://reproducible-builds.org/specs/source-date-epoch/
>
> What happens if other distros decide not to use this environment variable?
> Do I really want distro specific code in the package?

For what it is worth, it seem like it will make its way into CPython as well:
https://github.com/python/cpython/pull/296

And IFAICT, this env variable naming is already more than just debian.

-- 
M


>
> In addition we already have our own mechanism for making the produced
> documents
> invariant although it might require an extension to support externally
> specified date & time as in the debian variable.
>
> In short where does the distro responsibility and package maintainers
> boundary need to be?
> --
> Robin Becker
> ___
> 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] GSoC 2017 - Working on pip

[Matthias Bussonnier]

Hi all,

Assuming that all the requirements are wheels and coming from PyPI.
Installed using a recent pip.

How often do you think the resolution will be the same for all
clients, and mostly be "pull everything from latest" ?

If so, would it make sense to pre-compute thing on PyPI/warehouse at
package publication time, and provide a resolution "hint" as an API
endpoint ? If this "hint" is correct, it should avoid clientside work
most of time. And the resolution can probably be efficiently updated
as you only have to re-solve by looking as the dependees of previous
version.

-- 
M


On Fri, Feb 10, 2017 at 1:36 PM, Donald Stufft  wrote:
>
> On Feb 10, 2017, at 2:53 PM, Sebastien Awwad 
> wrote:
>
> If dependencies were knowable in static metadata, there would be a decent
> case for SAT solving. I'll try to get back to a write-up after the current
> rush on my main project subsides.
>
>
>
> The differences between backtracking and SAT solvers and such is perhaps a
> bit of of my depth, but just FWIW when installing from Wheel it’s basically
> just waiting on a new API to get this information in a static form.
> Installing from sdist still has the problem (and likely will forever) but I
> think it’s not *unreasonable* to say that using wheels is what you need to
> do to get fast dep solving and if people aren’t providing wheels it will be
> slow(er?).
>
> —
> Donald Stufft
>
>
>
>
> ___
> 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] latest setuptools appears to require six in a breaking way

[Matthias Bussonnier]

> Just because it's on the release notes doesn't mean its not an issue.

Sorry if I miss expressed myself, let me retry:

If it is on the release notes, then it is likely because the
maintainers are aware. And if they released this version with this in
the release notes, then trying to fill a bug will likely result in it
being dismissed as duplicate.
I tried to be too concise.

I don't disagree that this change is likely to be quite painful, and I
have not contributed enough to setuptools to contradict the choice the
maintainers have had. I just linked to (and cited) the release notes,
gave a reason as I was aware (since yesterday, made /r/python top 10)
of why you were seeing what you are seeing.

I do understand the difficulty to upgrade all the CI script and
library. I've been in the process of upgrading our test suite and test
of all the packages I maintain to make sure we don't use
DeprecatedBehavior of 3.6 (Oh invalid backslash escape sequence is fun
in docstring that give example with windows Path). So yes that a
couple of weeks of low productivity. But at the same time that's the
price I chose to pay to support such a wide range of versions and have
sofware from 2 differents decades to work together.

I want to add that if your system is still using old pip/setuptools
version then it might soon break for other reasons. Setuptools < 24
(IIRC) and pip < 9 cannot handle Python 3 only Sdist correctly. So if
one of your libraries you use publish a Python 3 only sdist (which is
likely to happen at some point in time) then your CI will install the
latest python 3 only sdist on python 2 instead of the latest Python 2
compatible sdist. Which is likely to fail as well.

So at some point upgrading pip and setuptools as a first step of CI
integration might be anyway necessary.

Hope this problem will be either accepted or solved soon.

Thanks
-- 
M





On Wed, Jan 25, 2017 at 9:20 AM, Chris Withers <ch...@simplistix.co.uk> wrote:
> On 25/01/2017 16:44, Matthias Bussonnier wrote:
>>
>> AFAICT this is not really an issue as this is on the release notes:
>>
>> https://setuptools.readthedocs.io/en/latest/history.html#v34-0-0
>
>
> Just because it's on the release notes doesn't mean its not an issue.
>
>>> #581: Instead of vendoring the growing list of dependencies that
>>> Setuptools requires to function, Setuptools now requires these dependencies
>>> just like any other project. Unlike other projects, however, Setuptools
>>> cannot rely on setup_requires to demand the dependencies it needs to install
>>> because its own machinery would be necessary to pull those dependencies if
>>> not present (a bootstrapping problem). As a result, Setuptools no longer
>>> supports self upgrade or installation in the general case. Instead, users
>>> are directed to use pip to install and upgrade using the wheel distributions
>>> of setuptools.
>
>
> For such a fundamental part of the python packaging ecosystem, that's a
> pretty disappointing change. Not supporting self-upgrade seems like a pretty
> massive regression, and the problems here are a result.
>
> None of the problems I've had involve explicit installation of setuptools,
> it seems to be dragged in as a dependency somewhere along the way. The lack
> of ability to self-update in that situation is going to cause major pain.
>
>>  >As discovered in #940, not all versions of pip will successfully
>> install Setuptools from its pre-built wheel. If you encounter issues
>> with “No module named six” or “No module named packaging”, especially
>> following a line “Running setup.py egg_info for package setuptools”,
>> then your pip is not new enough.
>
>
> Right, so what's the recommended one-step way to set up a virtualenv now in
> Py 2.6-3.6?
>
>>> There’s an additional issue in pip where setuptools is upgraded
>>> concurrently with other source packages, described in pip #4253. The
>>> proposed workaround is to always upgrade Setuptools first prior to upgrading
>>> other packages that would upgrade Setuptools.
>
>
> That workaround is quite painful if you maintain any number of libraries
> that have CI scripts that will need to be hacked up to support the
> workaround and then reverted after the issue is finally fixed.
>
> Sorry if this comes across as negative, I know it's not always easy to judge
> the outcome of changes before a big release, but I do hope something can be
> done to mitigate the pain of library maintainers doing the right thing and
> running CI...
>
> cheers,
>
> Chris
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] latest setuptools appears to require six in a breaking way

[Matthias Bussonnier]

AFAICT this is not really an issue as this is on the release notes:

https://setuptools.readthedocs.io/en/latest/history.html#v34-0-0

You need to upgrade pip  (cf 3rd paragraph):

> #581: Instead of vendoring the growing list of dependencies that Setuptools 
> requires to function, Setuptools now requires these dependencies just like 
> any other project. Unlike other projects, however, Setuptools cannot rely on 
> setup_requires to demand the dependencies it needs to install because its own 
> machinery would be necessary to pull those dependencies if not present (a 
> bootstrapping problem). As a result, Setuptools no longer supports self 
> upgrade or installation in the general case. Instead, users are directed to 
> use pip to install and upgrade using the wheel distributions of setuptools.

> Users are welcome to contrive other means to install or upgrade Setuptools 
> using other means, such as pre-installing the Setuptools dependencies with 
> pip or a bespoke bootstrap tool, but such usage is not recommended and is not 
> supported.

 >As discovered in #940, not all versions of pip will successfully
install Setuptools from its pre-built wheel. If you encounter issues
with “No module named six” or “No module named packaging”, especially
following a line “Running setup.py egg_info for package setuptools”,
then your pip is not new enough.

> There’s an additional issue in pip where setuptools is upgraded concurrently 
> with other source packages, described in pip #4253. The proposed workaround 
> is to always upgrade Setuptools first prior to upgrading other packages that 
> would upgrade Setuptools.

-- 
M

On Wed, Jan 25, 2017 at 6:46 AM, Robin Becker  wrote:
>
> On 25/01/2017 10:41, Chris Withers wrote:
>>
>> Hi All,
>>
>> Anyone else seen this?
>>
>> |File
>>
>> "/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/setuptools/__init__.py",
>> line 10, in  from six.moves import filter, map ImportError: No
>> module
>> named six.moves|
>>
> My colleague just came across this when creating a new venv.
>
> We then installed six, but our setup then went on to complain about
> packaging and then finally appdirs before it went through.
>
> Each time the fix was to manually install the thing that pip complained
> about.
>
>
>>
>> Started happening in my nightly builds on travis after the 34.0.2 release
>> of
>> setuptools. I've filed an issue here since I suspect it isn't just me:
>>
>> https://github.com/pypa/setuptools/issues/945
>>
>> cheers,
>>
>> Chris
>>
>>
>>
>> ___
>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
>
> --
> Robin Becker
> ___
> 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] Limit package installation to a specific Python version

[Matthias Bussonnier]

Hi all,

On Fri, Jan 20, 2017 at 2:56 PM, Nathaniel Smith  wrote:
> On Fri, Jan 20, 2017 at 1:56 PM, Lele Gaifax  wrote:
>> Hi all,
>>
>> do installers like pip and conda consult trove classifiers, or more generally
>> is there a way to "mark" a package published on PyPI as installable only in a
>> Python 3 environment?
>>

>  For sdists, historically there was no way to do this, but as of a
> few months ago this was fixed and pip now *does* honor
> python_requires, and PyPI has been updated to expose this information
> so pip can see it before downloading the sdists:
>
> https://github.com/pypa/pip/pull/3846
> https://github.com/python/peps/pull/56
> https://github.com/pypa/pip/pull/3877
>
> Since this is a pretty recent change, you probably want to put a
> runtime check inside your setup.py for old Python versions, so if
> someone uses an old version of pip then they will at least get a nice
> explanation.
>
> IPython's an example of a python-3-only project that uses this
> belt-and-suspenders approach:
>
> https://github.com/ipython/ipython/blob/f060158665189fd456e54a5a864080efe28b4fdf/setup.py#L29
> https://github.com/ipython/ipython/blob/f060158665189fd456e54a5a864080efe28b4fdf/setup.py#L248
>

I'm also in the (slow) process of writing the various step you can
take when python_requires is not honored by older systems and how to
mitigate that:

https://github.com/python3statement/python3statement.github.io/pull/55

Feedback (and help) would be welcome.

In particular only system where pip 9.0+ is installed will understand
the metadata now exposed by PyPI,
so when/if you fail in your setup.py, a useful tip is to ask user to
upgrade pip.

There should be some snipets of code you copy and past in your
setup.py in this PR as well.

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

Re: [Distutils] RFC 2: PEP 541 - Package Index Name Retention

[Matthias Bussonnier]

> One thing we could possibly do is provide the ability for, as part of the
> relqunishing process, “lock” the old versions that were uploaded so that the
> new owner can neither delete them or upload new files for them AND set a
> “minimum version” for new uploads for that project. This could mean that one
> could say that foobar < 4.0 is the old project and foobar >= 4.0 is the new
> project and existing == continue to work. I’m not sure I feel about that
> though.


Wouldn't that be a case where the version epoch[1] could (should?) be used ?

> If included in a version identifier, the epoch appears before all other 
> components, separated from the release segment by an exclamation mark:

> E!X.Y  # Version identifier with epoch
> If no explicit epoch is given, the implicit epoch is 0 .

> Most version identifiers will not include an epoch, as an explicit epoch is 
> only needed if a project changes the way it handles version numbering in a 
> way that means the normal version ordering rules will give the wrong answer.

-- 
M

1:https://www.python.org/dev/peps/pep-0440/#version-epochs
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] RFC 2: PEP 541 - Package Index Name Retention

[Matthias Bussonnier]

On Mon, Jan 16, 2017 at 1:18 PM, Chris Rose  wrote:
> The tricky part there is that "being used" is a tough concept to define.
> Over what time period? What amount of downloading counts as "used"?
>
> I believe these concepts need to be made very clear, because the impact of
> exploitative replacement is pretty severe if it is made to happen.
>

Would a month  where the old package is made unavailable, but the new
owner is not given access yet be a good compromise ?

It most likely let time the old owner (or old users) to manifest a
decide to "revive" the package if necessary, otherwise give a really
strong signal that if there is still a couple of download, then it
really does not breaks a lot.
-- 
M
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Matthias Bussonnier]

On Tue, Sep 13, 2016 at 3:55 PM, Donald Stufft  wrote:

> Perhaps a better idea would be to add some smarts to the REPL (but not to 
> Python itself) that would detect something like:
>
 pip install
>
> And print a better error message that gives a better indication about what’s 
> gone wrong besides a SyntaxError?

I've that for IPython:

https://pypi.python.org/pypi/pip_magic

It need to be loaded explicitly, but I'm[1] considering making it
enabled by default.

We're more and more encountering users that are confused with
installing form within the shell; More and more users are in a Python
REPL[2] long before even knowing what a shell command line is and how
to get one. Worse they can choose environment in a dropdown, so having
to tell them they need to activate the env to install things make no
sens for them.

I think a 'pip install', or whatever else that could hook into the
thing to install package (like something that conda could set to
theirown thing) would be great. A message like "You might need to
restart your Python interpreter for changes to be taken into account"
seem enough to C.Y.A and would get us 90% there.

-- 
M

[1] I think other dev agree with me.
[2] in a notebook most of the time
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Pep 440 question/clarification Version specifiers no "Or" available

[Matthias Bussonnier]

Hi all,

In the line of recent discussions[1] about releasing some packages
only for some versions of Python.

I was reading pep 440 and in particular the "Version specifier section".

The following sentence caught my eye:

> The comma (",") is equivalent to a logical and operator: a candidate version 
> must match all given version clauses in order to match the specifier as a 
> whole.


Is there no way to have an "or" ? It seem to me that it might be
useful for package wanting to express compatibility with `2.6`, `2.7`
or `>3.3` for example, in the form `=~2.6  =~3.3`.

I completely agree that the use case is _limited_ and likely rare, I
was just wondering if I'm missing something, if it was an oversight
and if not if adding a section detailing that "or" was not considered,
or that "or" was explicitly not included for X,Y,Z reason would be a
good thing.

Thanks,
-- 
Matthias



[1]:https://mail.python.org/pipermail/distutils-sig/2016-August/029604.html
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig