New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Packaging: Add placeholder packages #472
Conversation
|
Shouldn't we have build dependency on |
|
I'm not an expert about how PyPI is working, but shouldn't be there also placeholder packages for:
How about [free]ipa-server and friends, can a bad person use this for an attack when somebody uses |
configure.ac
Outdated
| @@ -577,6 +577,9 @@ AC_CONFIG_FILES([ | |||
| ipaserver/Makefile | |||
| ipatests/Makefile | |||
| ipatests/man/Makefile | |||
| packaging/Makefile | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we rename this to wheel_packaging or pypi_packaging to be clear what is the purpose, because it is only for bdist_wheel
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! how about just pypi?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or pypi_placeholders
|
At the moment wheels are not required for RPM building. python-wheel is not available on RHEL, but I can work around it. Should the RPM spec file only contain dependencies for RPM packaging or also dependencies for general development and general packaging? I can create placeholder modules for ipaserver, ipaplatform and ipatests, too. It's going to be a bit more tricky. Let's see... |
1218451
to
2963ad3
Compare
|
Is this really the right thing to do? IMO it does not make much sense to have placeholders for every |
|
We want to prevent others to have packages in PyPI with the same names as used for IPA. This is reasonable for protecting users to get attacker code from PyPI and rewrite working modules installed from rpms. In case that somebody install |
|
Yes, it is the right thing to do. You can trust in the expert with a decade of experience with Python packaging (formerly known as cheese shop). |
2963ad3
to
ce38000
Compare
|
I talked with Honza how to handle the build dependency for pypi, and we may to remove the commit that adds python-wheel or add new option to specfile that will install pypi related packages Do you plan to have more dependencies related only to pypi? |
|
You requsted a dependency in the first place :) If you are going to add a special build or dependency flavor for PyPI packaging, please also add |
ce38000
to
8b8a1dc
Compare
|
OK, you got |
|
Thank you. I see errors reported by pylint |
|
LGTM, please rebase and I will test it. |
8b8a1dc
to
1febac3
Compare
|
@MartinBasti I have rebased the branch and added wheel + placeholder building to make check. The pylint violations have disappeared. |
|
Is really needed to have this in make check? It makes build dependencies of wheel mandratory not optional |
|
I'm open to suggestions here, but I like to have automatic validation of packaging. |
|
I agree with @MartinBasti it is not a unit test. |
|
That's not the point here. We are arguing about a new build dependency (python-wheel). |
|
FYI: At the moment, The reason is that required dependencies are not in some downstream distributions and IIRC python-wheel is not there either. |
|
Some distros like RHEL doesn't have python-wheel packaged. It can be disabled by downstream patch, but better would be to remove it or make it configurable. |
|
NACK for downstream patch. The intention of build system refactoring was make packaging in downstream simpler. |
|
@tiran I thought we agreed on having My only concern it to not run wheel build in make check |
1febac3
to
53f3d41
Compare
|
@MartinBasti I dropped the last commit. make check no longer checks wheel packages. I'm going to open a new ticket for @martbab and ask him to add to add a proper test for wheel building to his awesome container magic. |
|
The old pylint issue is back |
| pypi_packages: bdist_wheel wheel_placeholder | ||
| @echo -e "\n\nTo upload packages to PyPI, run:\n" | ||
| @echo -e " twine upload $(WHEELDISTDIR)/*-$(VERSION)-py2.py3-none-any.whl\n" | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason why top-level make need to be polluted with this new build targets?
They can be just in pypi/Makefile.am.
It will simplify IPA_PLACEHOLDERS; you will iterate over all SUBDIRS there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, there are. If you look closely you will notice that the new target depends on bdist_wheel and wheel_placeholder and the placeholder parts creates wheels in dist/wheels. It doesn't maek sense to have the target just in pypi.
My first version iterated over subdirs in ./pypi. This doesn't work for ipacommands (next PR) because ipacommands must be built as sdist, not bdist_wheel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can move all following make targets bdist_wheel wheel_bundle wheel_placeholder pypi_packages into pypi/Makefile.am
(including all dependencies.
The top level make file will be simpler. The same as before wheel/pypy effort.
And Makefile.am in sub directory pypy will be python only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I respectfully decline your suggestion.
- It's much more important to make package building and testing easy to use than to keep the top level Makefile simple.
- The top level Makefile is the public interface. Sublevel makefiles are helpers. I don't like to have targets in sublevel makefiles that are not usable from the top level Makefile.
- The targets are easily discoverable, .e.g. with
make <tab>.
</bikeshedding>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like to have bdist_wheel accessible from the top makefile too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that could be solved with
wheel_placeholder:
$(MAKE) -C $(top_builddir)/pypi wheel_placeholder
It would make the main Makefile nicer+simpler but that's just nice to have
The main problem is not in this PR but in structure of directories in freeipa git.
There are not sub-directories for Python code/C-code/javascript code...
As a result of this there are many *.SUBDIR variables in top level makefile to workaround this directory structure.
I thought that moving some *.SUBDIR variables to pypi/Makefile.am would simplify it.
Sorry for a little noise.
|
Commit 1f8326a fixes an issue in |
The ipa and freeipa packages are placeholders to prevent PyPI squashing attacks and reserve the names for future use. `pip install ipa` installs ipaclient. Signed-off-by: Christian Heimes <cheimes@redhat.com>
Signed-off-by: Christian Heimes <cheimes@redhat.com>
I also renamed the base directory to pypi and added a new build target pypi_packages. Signed-off-by: Christian Heimes <cheimes@redhat.com>
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Some calls to setup.py specified a build base, some did not. This can lead to issues, e.g. build, clean and install are using different build directories. Signed-off-by: Christian Heimes <cheimes@redhat.com>
1f8326a
to
6839d95
Compare
pylint gets confused by duplicated package names, e.g. ipaplatform and pypi/ipaplatform. Signed-off-by: Christian Heimes <cheimes@redhat.com>
Makefile.python.am
Outdated
| @@ -20,7 +19,7 @@ all-local: $(top_builddir)/ipasetup.py | |||
| --build-base "$(abs_builddir)/build" | |||
|
|
|||
| install-exec-local: $(top_builddir)/ipasetup.py | |||
| if [ "x$(pkginstall)" = "xtrue" ]; then \ | |||
| if [ "x$(pkginstall)" != "xfalse" ]; then \ | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I miss explanation why in commit message
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Default to pkginstall=true without duplicated definitions
automake was complaining about duplicated definition. I dropped pkginstall=true from Makefile.python.am and only set it in special Makefile.am
automake was complaining about duplicated definitions of pkginstall. It was defined to true in Makefile.python.am only to be overriden in some Makefile.am. Now we assume that pkginstall is implicit true and only skip installation when pkginstall is explicitly set to false. Signed-off-by: Christian Heimes <cheimes@redhat.com>
b443513
to
15535d6
Compare
|
master:
|
The ipa and freeipa packages are placeholders to prevent PyPI squashing
attacks and reserve the names for future use.
pip install ipainstallsipaclient.
Signed-off-by: Christian Heimes cheimes@redhat.com
The new PR provides just the two placeholder packages from PR #379.