Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Python plugin improvements #771
Conversation
sergiusens
added some commits
Aug 31, 2016
elopio
reviewed
Sep 1, 2016
| logger = logging.getLogger(__name__) | ||
| -class Python2Plugin(snapcraft.BasePlugin): | ||
| +class Python2Plugin(python3.Python3Plugin): |
elopio
Sep 1, 2016
Member
this is not a great idea, conceptually. Python3 is not a parent of python2, so inheritance could cause problems in the future. A better approach might be to make a common BasePythonPlugin, and inherit both Python2 and Python3 plugins from it.
sergiusens
Sep 1, 2016
Collaborator
and where would BasePythonPlugin live? in the python3 module or the python2 one?
sergiusens
Sep 1, 2016
Collaborator
El 01/09/16 a las 11:04, Leo Arias escribió:
In snapcraft/plugins/python2.py
#771 (comment):logger = logging.getLogger(name)
-class Python2Plugin(snapcraft.BasePlugin):
+class Python2Plugin(python3.Python3Plugin):neither. In a common module.
I don't know, this gives the plugins we write special treatment, this
module would have to be a plugin as well and we risk having a useless
plugin like the jdk one.
sergiusens
added some commits
Sep 1, 2016
elopio
reviewed
Sep 1, 2016
| @@ -237,17 +237,15 @@ def parallel_build_count(self): | ||
| # Helpers | ||
| def run(self, cmd, cwd=None, **kwargs): | ||
| - if cwd is None: | ||
| + if not cwd: | ||
| cwd = self.builddir | ||
| if True: |
elopio
reviewed
Sep 1, 2016
| +"""The python plugin can be used for python 2 or 3 based parts. | ||
| + | ||
| +The python plugin can be used for python projects where you would | ||
| +want to do: |
elopio
reviewed
Sep 1, 2016
| + 'python-setuptools', | ||
| + ] | ||
| + else: | ||
| + return [] |
elopio
Sep 1, 2016
Member
raise an exception? This should never happen.
Now this is a good use for assert :p
elopio
reviewed
Sep 1, 2016
| + } | ||
| + schema['properties']['python-version'] = { | ||
| + 'type': 'string', | ||
| + 'default': 'python3', |
sergiusens
Sep 1, 2016
Collaborator
El 01/09/16 a las 12:56, Leo Arias escribió:
In snapcraft/plugins/python.py
#771 (comment):
schema['properties']['python-packages'] = {'type': 'array','minitems': 1,'uniqueItems': True,'items': {'type': 'string'},'default': [],}schema['properties']['process-dependency-links'] = {'type': 'boolean','default': False,}schema['properties']['python-version'] = {'type': 'string','default': 'python3',is there a way to enforce the two valid values?
yes I added an enum
elopio
reviewed
Sep 1, 2016
| + 'constraints', | ||
| + 'python-packages', | ||
| + 'python-version', | ||
| + ]) |
elopio
Sep 1, 2016
Member
What about the build properties?
I'm not sure how does this work. If the pull properties are changed, and snapcraft build is executed, will it run pull again?
elopio
reviewed
Sep 1, 2016
| + elif self.options.python_version == 'python2': | ||
| + return ['python2'] | ||
| + else: | ||
| + return [] |
elopio
reviewed
Sep 1, 2016
| @@ -1,6 +1,6 @@ | ||
| # -*- Mode:Python; indent-tabs-mode:nil; tab-width:4 -*- | ||
| # | ||
| -# Copyright (C) 2015 Canonical Ltd | ||
| +# Copyright (C) 2015-2016 Canonical Ltd |
sergiusens
Sep 1, 2016
Collaborator
El 01/09/16 a las 13:01, Leo Arias escribió:
In snapcraft/plugins/python3.py
#771 (comment):@@ -1,6 +1,6 @@
-- Mode:Python; indent-tabs-mode:nil; tab-width:4 --
-# Copyright (C) 2015 Canonical Ltd
+# Copyright (C) 2015-2016 Canonical Ltd2015, 2016
we already had this discussion ;-)
elopio
reviewed
Sep 1, 2016
| @@ -16,6 +16,8 @@ | ||
| """The python3 plugin can be used for python 3 based parts. | ||
| +This plugin is DEPRECATED in favor of the python plugin. |
elopio
reviewed
Sep 1, 2016
| return schema | ||
| def __init__(self, name, options, project): | ||
| + setattr(options, 'python_version', 'python2') |
sergiusens
Sep 1, 2016
Collaborator
Because it doesn't exist, options gets created from the plugin's schema
|
oh, yes! /me approves. |
sergiusens
added some commits
Sep 1, 2016
SamYaple
reviewed
Sep 1, 2016
| + elif self.options.python_version == 'python2': | ||
| + return ['python'] | ||
| + else: | ||
| + raise AssertionError('python-version has a value of {!r}'.format( |
SamYaple
Sep 1, 2016
Contributor
no reason to do this. just don't pop 'required' from the options schema. enforce the requirement of python_version (and specific values with enum so we dont have to validate it either)
elopio
Sep 1, 2016
Member
yup, and this could be a dictionary. return self._python_stage_packages[self.options.python_version]
Then an exception would be raised anyway if there is a programmer error somewhere.
sergiusens
Sep 1, 2016
•
Collaborator
the problem is on inheritance. Adding the schema makes the option visible to the python2 and python3 plugins
SamYaple
Sep 3, 2016
Contributor
Hmmm. I suppose schema could be added to the children too if that a problem.
I just don't like the idea of checking python versions in multiple places. Perhaps abstract the else to another function so we don't have to change exceptions in multiple places should this need to be handled differently in the future? (I'm seeing potential uses for python3.4 vs python3.5 maybe). I just don't like violating DRY in this way.
|
I think this is very good. I left some minor ignorable comments, so you'll have my +1... |
|
You beat me to it! Glad you also like the approach of python2 and python3 inheriting a 'python' plugin for deprecation. I could think of no other way to do it |
sergiusens
added some commits
Sep 1, 2016
|
LP: #1616032 |
sergiusens
self-assigned this
Sep 2, 2016
sergiusens
added some commits
Sep 3, 2016
|
LP: #1616407 |
|
LP: #1606894 |
|
LP: #1602079 |
|
retest this please |
|
LP: #1594809 |
|
retest this please |
|
LP: #1607297 |
elopio
reviewed
Sep 7, 2016
| @@ -235,3 +245,16 @@ def snap_fileset(self): | ||
| elif self.options.python_version == 'python2': | ||
| fileset.append('-**/*.pyc') | ||
| return fileset | ||
| + | ||
| + | ||
| +def _replicate_owner_mode(path): |
|
Merge merge merge Patchset looks good. I have been using it exclusively for a few days now. Possibly some docs/testing stuff that is needed, but functionally it is solid. |
|
when trying to snap integration_tests/snaps/pip-requirements-list, it results in a conflict with bin/jsonschema. This is known, right? It's part of the change you commented in the mailing list about entry points? |
|
El 07/09/16 a las 00:32, Leo Arias escribió:
There is a fileset the takes this into account, integration tests pass, |
|
LP: #1619104 |
sergiusens commentedAug 31, 2016
•
Edited 1 time
-
sergiusens
Aug 31, 2016
The unit tests still need updating, what do people think about this approach?
The demos still work btw.