On 8 December 2013 02:01, Nick Coghlan wrote:
>> Maybe what we want is a sysconfig path "root" that explicitly encodes
>> the filesystem root.
>
> s/filesystem root/installation root/
>
> I'm assuming that's what you meant, since you'd know better than I do
> that "filesystem root" isn't a particu
On 8 December 2013 08:22, Paul Moore wrote:
> On 7 December 2013 21:32, Marcus Smith wrote:
>> actually, bdist_wheel doesn't handle absolute paths in the "data_files"
>> keyword like standard setuptools installs do, which honor it as absolute
>> (which seems to match the examples in the distutils
On 7 December 2013 21:32, Marcus Smith wrote:
> actually, bdist_wheel doesn't handle absolute paths in the "data_files"
> keyword like standard setuptools installs do, which honor it as absolute
> (which seems to match the examples in the distutils docs)
> when using absolute paths, the data ends
https://bitbucket.org/dholth/wheel/issue/92/bdist_wheel-makes-absolute-data_files
On Sat, Dec 7, 2013 at 1:32 PM, Marcus Smith wrote:
> actually, bdist_wheel doesn't handle absolute paths in the "data_files"
> keyword like standard setuptools installs do, which honor it as absolute
> (which see
actually, bdist_wheel doesn't handle absolute paths in the "data_files"
keyword like standard setuptools installs do, which honor it as absolute
(which seems to match the examples in the distutils docs)
when using absolute paths, the data ends up in the packaged wheel at the
top level (not in the {
> As part of the docs clarification, I was planning to point out that such
> layouts are almost always platform (and even distro) specific. That's still
> a valid use case for sdist and wheel, though, so it makes sense to me to
> document it properly.
>
> My other related question is whether it's p
As part of the docs clarification, I was planning to point out that such
layouts are almost always platform (and even distro) specific. That's still
a valid use case for sdist and wheel, though, so it makes sense to me to
document it properly.
My other related question is whether it's possible to
On 7 December 2013 11:10, Michael Jansen wrote:
> I guess we agree here. But people already do that because they have no other
> choice. Nick only wants to document the way it works better. Many people
> already figured this out and use it anyway.
I believe it's an "attractive nuisance" and shoul
On Saturday, December 07, 2013 10:26:15 AM Paul Moore wrote:
> On 7 December 2013 08:19, Nick Coghlan wrote:
> > That means that you can ship relatively arbitrary software in a wheel
> > file by dumping it in "{distribution}-{version}.data/data/", and
> > then installing it to the appropriate targ
On Saturday, December 07, 2013 06:19:42 PM Nick Coghlan wrote:
> In the binary dependency management threads, Daniel pointed out that
> in all currently defined sysconfig schemes, the "data" directory will
> end up pointing to the target installation directory. The "data" name
> in the scheme doesn
On 7 December 2013 08:19, Nick Coghlan wrote:
> That means that you can ship relatively arbitrary software in a wheel
> file by dumping it in "{distribution}-{version}.data/data/", and
> then installing it to the appropriate target location (e.g. if you use
> FHS paths inside the data directory, t
In the binary dependency management threads, Daniel pointed out that
in all currently defined sysconfig schemes, the "data" directory will
end up pointing to the target installation directory. The "data" name
in the scheme doesn't actually mean "this is a data file", it means
"this has no defined s
12 matches
Mail list logo
