Re: [Distutils] pythonhosted.org doc upload no longer works
A bare redirect would also be fine. It's a shame setup.py classifiers /
metadata does not have a "documentation" field otherwise
pythonhosted.org/{project_name} could have automatically redirected to the
project doc.
Perhaps https://pypi.python.org/pypi?:action=pkg_edit&name={project_name}
could provide a form where this can be specified.
What do you think?
On Tue, Sep 5, 2017 at 12:49 PM, Noah Kantrowitz
wrote:
> This was discussed several years ago in https://mail.python.org/
> pipermail/distutils-sig/2015-May/026381.html and a few other threads. The
> final phases went out earlier this year. I don't think there is any plan to
> re-enable uploads to pythonhosted at this time. If you want a one-off
> redirect change or just having the old files removed, we can probably do
> that though, but I very much defer to Donald and others on that :)
>
> --Noah
>
> > On Sep 4, 2017, at 9:43 PM, Giampaolo Rodola'
> wrote:
> >
> > I think it's wise to revert that commit. It seems pythonhosted only
> suggested to migrate to RTD but there never was an official shutdown date
> or warning (either via direct email or message on the web page).
> >
> > On Tue, Sep 5, 2017 at 12:19 PM, Berker Peksağ
> wrote:
> > On Mon, Sep 4, 2017 at 4:56 PM, Nick Coghlan wrote:
> > > On 2 September 2017 at 15:34, Giampaolo Rodola'
> wrote:
> > >> I know it was deprecated long ago in favor of readthedocs but I kept
> > >> postponing it and my doc is still hosted on
> > >> https://pythonhosted.org/psutil/.
> > >
> > > While we've talked about deprecating it, it *hasn't* been deprecated.
> > > Looking at https://github.com/pypa/pypi-legacy/commits/production, I'm
> > > not seeing anything obvious that would have caused problems with docs
> > > management, but that's probably still the best issue tracker to use to
> > > report the bug.
> >
> > See the 'doc_upload' handler at
> > https://github.com/pypa/pypi-legacy/commit/
> 1598e6ea0f7fb0393891f6c6bcbf84c191834a0e#diff-
> 19fadc30e1b17100568adbd8c6c3cc13R2804
> > I've collected all information I found at
> > https://github.com/pypa/pypi-legacy/issues/672#issuecomment-316125918
> > Please correct me if I missed anything.
> >
> > --Berker
> > ___
> > Distutils-SIG maillist - Distutils-SIG@python.org
> > https://mail.python.org/mailman/listinfo/distutils-sig
> >
> >
> >
> > --
> > Giampaolo - http://grodola.blogspot.com
> >
> > ___
> > 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
>
--
Giampaolo - http://grodola.blogspot.com
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] string types for paths in PEP 517
I considered this. It's *potentially* a problem, but I think we should not try to deal with it for now: - Normally, temp files will go in /tmp - so it should be fine to construct paths of entirely ascii characters. - Frontends that want the wheel to end up elsewhere can ask for it in a tmp directory first and then move it, so there's a workaround if it becomes an issue. - We already have workarounds for the commonest case of UTF-8 paths + C locale: ignore the locale and treat paths as UTF-8. - The 'right' way to deal with it on Unix is to make all paths bytes, which would introduce a similar issue on Windows. If paths have to be bytes in some situations and unicode in others, both frontends and backends need extra complexity to handle that. - If your non-ascii username breaks stuff on Python 2... Python 3 is ready to make your life easier. Thomas On Tue, Sep 5, 2017, at 07:33 AM, Nathaniel Smith wrote: > Hi all, > > Quick question about an arcane topic: currently, PEP 517 says that > paths are always represented as unicode strings. For example, when the > frontend calls build_wheel, it has to create a temporary dir to hold > the output wheel, and it passes this in as an absolute path > represented as a unicode string. > > In Python 3 I think this is totally fine, because the surrogate-escape > system means that all paths can be represented as unicode strings, > even on systems like Linux where you can have paths that are invalid > according to Python's idea of the filesystem encoding. > > In Python 2, if I understand correctly (and I'm not super confident > that I do), then there is no surrogate-escape, and it's possible to > have paths that can't be represented as a unicode object. For example, > if someone's home directory is /home/stéfan in UTF-8 but Python thinks > that the locale is C, and a frontend tries to make a tmpdir in > $HOME/.local/tmp/ and pass it to a backend then... everything blows > up, I guess? > > So I guess this is a question for those unfortunate souls who > understand these details better than me (hi Nick!): is this actually a > problem, and is there anything we can/should do differently? > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > ___ > 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] string types for paths in PEP 517
On 5 September 2017 at 09:00, Thomas Kluyver wrote: > I considered this. It's *potentially* a problem, but I think we should > not try to deal with it for now: > > - Normally, temp files will go in /tmp - so it should be fine to > construct paths of entirely ascii characters. > - Frontends that want the wheel to end up elsewhere can ask for it in a > tmp directory first and then move it, so there's a workaround if it > becomes an issue. > - We already have workarounds for the commonest case of UTF-8 paths + C > locale: ignore the locale and treat paths as UTF-8. > - The 'right' way to deal with it on Unix is to make all paths bytes, > which would introduce a similar issue on Windows. If paths have to be > bytes in some situations and unicode in others, both frontends and > backends need extra complexity to handle that. > - If your non-ascii username breaks stuff on Python 2... Python 3 is > ready to make your life easier. +1 on this Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] string types for paths in PEP 517
On Tue, Sep 5, 2017 at 1:00 AM, Thomas Kluyver wrote: > I considered this. It's *potentially* a problem, but I think we should > not try to deal with it for now: > > - Normally, temp files will go in /tmp - so it should be fine to > construct paths of entirely ascii characters. Does pip in fact use /tmp for temporary directories? (It's not always the right choice, because /tmp has limited space on some systems, e.g. b/c it's on a ramdisk. If we still had build_directory= then this could be an issue, since build directories can be arbitrarily large; maybe it's not a big deal now that we only need the tmpdir to handle a single sdist/wheel/dist-info.) > - Frontends that want the wheel to end up elsewhere can ask for it in a > tmp directory first and then move it, so there's a workaround if it > becomes an issue. > - We already have workarounds for the commonest case of UTF-8 paths + C > locale: ignore the locale and treat paths as UTF-8. Only in 3.7, I think? Or do you mean, backends should be doing this manually on Python 2? (To be clear, I think the current text is potentially fine, I just want to make sure I/we understand the full consequences instead of discovering them a year from now when we're stuck with them :-).) -n -- Nathaniel J. Smith -- https://vorpus.org ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] string types for paths in PEP 517
> > On Sep 5, 2017, at 4:36 AM, Nathaniel Smith wrote: > > Does pip in fact use /tmp for temporary directories? (It's not always > the right choice, because /tmp has limited space on some systems, e.g. > b/c it's on a ramdisk. If we still had build_directory= then this > could be an issue, since build directories can be arbitrarily large; > maybe it's not a big deal now that we only need the tmpdir to handle a > single sdist/wheel/dist-info.) It does by default yes. It just uses the tempfile module so it respects $TMPDIR directory and everything if people want to point it to a different directory. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] string types for paths in PEP 517
On 5 September 2017 at 01:36, Nathaniel Smith wrote: > On Tue, Sep 5, 2017 at 1:00 AM, Thomas Kluyver wrote: >> - We already have workarounds for the commonest case of UTF-8 paths + C >> locale: ignore the locale and treat paths as UTF-8. > > Only in 3.7, I think? Or do you mean, backends should be doing this > manually on Python 2? The frontend controls the locale that the backend runs in, so the frontend can set C.UTF-8 even if the frontend itself is launched in the C locale. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] string types for paths in PEP 517
+1 2017-09-05 3:21 GMT-05:00 Paul Moore : > On 5 September 2017 at 09:00, Thomas Kluyver wrote: > > I considered this. It's *potentially* a problem, but I think we should > > not try to deal with it for now: > > > > - Normally, temp files will go in /tmp - so it should be fine to > > construct paths of entirely ascii characters. > > - Frontends that want the wheel to end up elsewhere can ask for it in a > > tmp directory first and then move it, so there's a workaround if it > > becomes an issue. > > - We already have workarounds for the commonest case of UTF-8 paths + C > > locale: ignore the locale and treat paths as UTF-8. > > - The 'right' way to deal with it on Unix is to make all paths bytes, > > which would introduce a similar issue on Windows. If paths have to be > > bytes in some situations and unicode in others, both frontends and > > backends need extra complexity to handle that. > > - If your non-ascii username breaks stuff on Python 2... Python 3 is > > ready to make your life easier. > > +1 on this > Paul > ___ > 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] PEP 517 again
On Mon, Sep 4, 2017 at 6:00 AM, Nick Coghlan wrote: > >> Do the Linux distros use pip to build their packages? > > > > Not that I am aware of. > > Fedora's build macros for Python projects currently rely on running > setup.py directly, but we've been considering switching to pip instead > since 2013 or so. PEP 517 is likely to provide the impetus to switch > from "maybe we should do that" to "we need to do that, at least if > setup.py is missing, and potentially always, so we get more consistent > installation metadata" > which is exactly why I tried to do it in conda. In a post PEP 517 world, that may be a good way to go. I'm looking forward to it. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
