installing modules under another project's top-level namespace
Carl Meyer
Hash: SHA1
Hi all,
Just wanted to draw your attention briefly to
https://github.com/pypa/pip/issues/355 and raise the question of what
distutils2/packaging does when a project attempts to install files
directly underneath the top-level package of a different project. I
would think this should be disallowed at install time, though given the
RECORD file it's something that theoretically _could_ be supported (what
about if the files its trying to install overwrite existing files of the
other project?)
Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5513kACgkQ8W4rlRKtE2eAcQCfdaYRl9gTYGJ7S82FZyD5H7gh
BtcAoJexsKe8GjuK623ikGOtvon56+Q+
=XXZL
-----END PGP SIGNATURE-----
Carl Meyer
> Just wanted to draw your attention briefly tohttps://github.com/pypa/pip/issues/355and raise the question of what
> directly underneath the top-level package of a different project. I
> would think this should be disallowed at install time, though given the
> RECORD file it's something that theoretically _could_ be supported (what
> about if the files its trying to install overwrite existing files of the
> other project?)
if I'd file a d2 bug on this, but it seems like the mailing list might
be a better place than the bug tracker to first hash out what the
intention and desired behavior actually are.
Carl
Éric Araujo
> Just wanted to draw your attention briefly to
> https://github.com/pypa/pip/issues/355 and raise the question of what
> distutils2/packaging does when a project attempts to install files
> directly underneath the top-level package of a different project.
Like distutils, d2 does not catch this.
> I would think this should be disallowed at install time,
+1.
> though given the RECORD file it's something that theoretically
> _could_ be supported (what about if the files its trying to
> install overwrite existing files of the other project?)
I don’t see the benefit. Right now, it’s best for clarity and for
downstream OS packaging systems if we give each distribution its
top-level directory. In the future, I hop PEP 402 is accepted, and then
projects will be able to have one namespace, say myapp.plugins, and each
plugin will have its top-level directory.
Regards
Toshio Kuratomi
depending on whether that PEP can be implemented for python2) it seems like
this is a valid method of creating namespaces. Certainly, it seems to be
just as valid as the things that go on in the setuptools namespace
implementation.
I really felt the need to jump in here because of the reference to
"downstream OS packaging systems" though. I don't believe that there's an
inherent problem with this setup for downstream OS packaging. If files get
overwritten then there's a definite problem but simply installing files
and directories from one project underneath another project should not.
-Toshio
Pierre-Yves David
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> Just wanted to draw your attention briefly to
> https://github.com/pypa/pip/issues/355 and raise the question of what
> distutils2/packaging does when a project attempts to install files
> directly underneath the top-level package of a different project. I
> would think this should be disallowed at install time,
Mercurial currently groups it's extension under the hgext packackages. Other
well packaged extension should go there. As far as I understand your proposal
is to make it invalid. I either mis-understood your proposal or totally
disagree with you.
Mercurial is used here as an example. We probably could find a tons of other
example that make sense inside and outside the python eco-system.
Regards
--
Pierre-Yves David
Carl Meyer
Hash: SHA1
Hi Pierre-Yves,
On 09/27/2011 04:07 AM, Pierre-Yves David wrote:
> Mercurial currently groups it's extension under the hgext packackages. Other
> well packaged extension should go there.
This may have been true at one time, but I don't believe that it is
anymore. The reference pages on WritingExtensions [1] and
PublishingExtensions [2] make no mention of placing your extension in an
"hgext" package, and I looked at a few extensions, including popular
ones such as "hgsubversion", and most did not.
> As far as I understand your proposal
> is to make it invalid. I either mis-understood your proposal or totally
> disagree with you.
>
> Mercurial is used here as an example. We probably could find a tons of other
> example that make sense inside and outside the python eco-system.
I don't think it's as widespread as you think. As evidence for this,
consider that pip's uninstall feature has not supported such
accreted-packages ever since it was added over two years ago (and the
lack-of-support is quite drastic, as it uninstalls the entire top-level
package), and yet we received the first bug report about this last week.
That said, I actually don't feel all that strongly about it. With the
RECORD file we'd have the information we need to handle this without
problems. I just want to have an explicit decision made one way or the
other.
Carl
[1] http://mercurial.selenic.com/wiki/WritingExtensions
[2] http://mercurial.selenic.com/wiki/PublishingExtensions
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6B43sACgkQ8W4rlRKtE2dVgwCgqDDC3/1rp1pJ1ucftr6HEWbP
D/8An1hZ8sOzkQEcKmwY+teV6kfPjZMc
=CfD8
-----END PGP SIGNATURE-----
Éric Araujo
> I really felt the need to jump in here because of the reference to
> "downstream OS packaging systems" though. I don't believe that there's an
> inherent problem with this setup for downstream OS packaging. If files get
> overwritten then there's a definite problem but simply installing files
> and directories from one project underneath another project should not.
You’re right, thanks for weighing in. Debian also has no issues
installing the files from python-sqlalchemy-ext under the base directory
of python-sqlalchemy, or sphinxcontrib extensions, or hg-git and
hgsubversion under the hgext directory, as Pierre-Yves mentions.
In the light of this, I think I’ll have to reverse my conclusion and not
reject such use cases in d2.
Regards