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

Unable to specify version for custom plugin. #340

Closed
mrburrito opened this Issue Mar 7, 2016 · 40 comments

Comments

Projects
None yet
4 participants
@mrburrito

mrburrito commented Mar 7, 2016

I'm developing a custom plugin and can't get pybuilder to pull new versions when they're available. How do I specify min and/or locked version for a plugin pulled from a pypi repository?

@esc

This comment has been minimized.

Show comment
Hide comment
@esc

esc Mar 7, 2016

Member

IIRC there is no mechanism built in to do this (yet). @mriehl to confirm

Member

esc commented Mar 7, 2016

IIRC there is no mechanism built in to do this (yet). @mriehl to confirm

@mrburrito

This comment has been minimized.

Show comment
Hide comment
@mrburrito

mrburrito Mar 9, 2016

@arcivanov I'd like pybuilder to validate the plugin version each time it runs to determine if a newer version of the plugin is available (according to the version spec) and, if so, download the updated version. For -dev versions, I want it to check timestamps and/or dev[N] numbers in the repo to make sure it has the latest version. Basically, emulate maven's behavior for SNAPSHOT and release dependencies.

It doesn't seem to do any of that and I've resorted to running an rm ${venv}/lib/python2.7/site-packages/my_plugin* each time I update my plugin. This is not a scalable solution once this gets pushed out to our CI server and the rest of my dev team.

Am I missing something in my plugin definition that configures the version so pybuilder can check it? I saw the code in pluginloader._check_plugin_version, but I don't think that's getting hit. I can change my version spec in the use_plugin call to a later version than what's installed and everything continues to run without downloading the new plugin.

mrburrito commented Mar 9, 2016

@arcivanov I'd like pybuilder to validate the plugin version each time it runs to determine if a newer version of the plugin is available (according to the version spec) and, if so, download the updated version. For -dev versions, I want it to check timestamps and/or dev[N] numbers in the repo to make sure it has the latest version. Basically, emulate maven's behavior for SNAPSHOT and release dependencies.

It doesn't seem to do any of that and I've resorted to running an rm ${venv}/lib/python2.7/site-packages/my_plugin* each time I update my plugin. This is not a scalable solution once this gets pushed out to our CI server and the rest of my dev team.

Am I missing something in my plugin definition that configures the version so pybuilder can check it? I saw the code in pluginloader._check_plugin_version, but I don't think that's getting hit. I can change my version spec in the use_plugin call to a later version than what's installed and everything continues to run without downloading the new plugin.

@arcivanov

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Mar 9, 2016

Contributor

@mrburrito

https://github.com/pybuilder/pybuilder/blob/master/src/unittest/python/pluginloader_tests.py#L214

If you use use_plugin with version specification and set version according to https://www.python.org/dev/peps/pep-0440/#handling-of-pre-releases then pip will both pull and update prereleases for you. You can also use the VCS URL in which case plugin will always be reinstalled.

So either

use_plugin("pypi:your-plugin", "~=1.2.3.dev0")

or

use_plugin("vcs:http://github.com/...", plugin_module_name="plugin.module.name")

Please let me know if this works for you. You might have to play with the version spec a little to get exactly what you want, so please do read through PEP-0440 carefully.

Contributor

arcivanov commented Mar 9, 2016

@mrburrito

https://github.com/pybuilder/pybuilder/blob/master/src/unittest/python/pluginloader_tests.py#L214

If you use use_plugin with version specification and set version according to https://www.python.org/dev/peps/pep-0440/#handling-of-pre-releases then pip will both pull and update prereleases for you. You can also use the VCS URL in which case plugin will always be reinstalled.

So either

use_plugin("pypi:your-plugin", "~=1.2.3.dev0")

or

use_plugin("vcs:http://github.com/...", plugin_module_name="plugin.module.name")

Please let me know if this works for you. You might have to play with the version spec a little to get exactly what you want, so please do read through PEP-0440 carefully.

@mrburrito

This comment has been minimized.

Show comment
Hide comment
@mrburrito

mrburrito Mar 10, 2016

None of that is working.

The plugin I'm working on is currently at version 0.3.1, with a dev version of 0.4.0.dev. When I publish/upload via the pybuilder distutils plugin, it appended the date to the end of the dev version rather than a number, so I deployed 0.4.0.dev20160310151716 to our internal PyPi repository (Artifactory).

My original include was use_plugin('pypi:my-plugin', '>=0.3.0') which, correctly, did not grab the dev dependency.

I updated it to use_plugin('pypi:my-plugin', '~=0.4.0.dev') and '~=0.4.0.dev0', neither of which worked.

I published my dev version as a release, 0.4.0 and tried again, using ~=0.3, >=0.3 and >=0.3.0 as version specs and pybuilder did not pull either my new 0.4.0 release or the 0.4.0.dev artifact from the repository.

I'm still faced with a situation where the only way I can get it to pull an updated version is by removing the cached plugin from the virtual environment.

Any ideas?

mrburrito commented Mar 10, 2016

None of that is working.

The plugin I'm working on is currently at version 0.3.1, with a dev version of 0.4.0.dev. When I publish/upload via the pybuilder distutils plugin, it appended the date to the end of the dev version rather than a number, so I deployed 0.4.0.dev20160310151716 to our internal PyPi repository (Artifactory).

My original include was use_plugin('pypi:my-plugin', '>=0.3.0') which, correctly, did not grab the dev dependency.

I updated it to use_plugin('pypi:my-plugin', '~=0.4.0.dev') and '~=0.4.0.dev0', neither of which worked.

I published my dev version as a release, 0.4.0 and tried again, using ~=0.3, >=0.3 and >=0.3.0 as version specs and pybuilder did not pull either my new 0.4.0 release or the 0.4.0.dev artifact from the repository.

I'm still faced with a situation where the only way I can get it to pull an updated version is by removing the cached plugin from the virtual environment.

Any ideas?

@mrburrito

This comment has been minimized.

Show comment
Hide comment
@mrburrito

mrburrito Mar 10, 2016

Oh, the commands I'm running to attempt to get pybuilder to download the plugin are:

  • pyb -t
  • pyb my_plugin_task
  • pyb install_dependencies

mrburrito commented Mar 10, 2016

Oh, the commands I'm running to attempt to get pybuilder to download the plugin are:

  • pyb -t
  • pyb my_plugin_task
  • pyb install_dependencies
@esc

This comment has been minimized.

Show comment
Hide comment
@esc

esc Mar 10, 2016

Member

IIRC the "check-for-latest-version-of-plugin-and-install" never actually worked, but that was some weeks ago.

Member

esc commented Mar 10, 2016

IIRC the "check-for-latest-version-of-plugin-and-install" never actually worked, but that was some weeks ago.

@arcivanov

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Mar 10, 2016

Contributor

Um, weird, I'll debug and get back to you.

Contributor

arcivanov commented Mar 10, 2016

Um, weird, I'll debug and get back to you.

@esc

This comment has been minimized.

Show comment
Hide comment
@esc

esc Mar 10, 2016

Member

I just looked at the code and judging from this:

https://github.com/pybuilder/pybuilder/blob/master/src/main/python/pybuilder/pluginloader.py#L120

it would appear that it will upgrade if a version identifier is present.

Member

esc commented Mar 10, 2016

I just looked at the code and judging from this:

https://github.com/pybuilder/pybuilder/blob/master/src/main/python/pybuilder/pluginloader.py#L120

it would appear that it will upgrade if a version identifier is present.

@esc

This comment has been minimized.

Show comment
Hide comment
@esc

esc Mar 10, 2016

Member

Yeah, I can confirm that neither specifying the plugin with version or without will automatically upgrade it with a pyb install_dependencies.

Member

esc commented Mar 10, 2016

Yeah, I can confirm that neither specifying the plugin with version or without will automatically upgrade it with a pyb install_dependencies.

@esc

This comment has been minimized.

Show comment
Hide comment
@esc

esc Mar 10, 2016

Member

So, the ThirdPartyPluginLoader https://github.com/pybuilder/pybuilder/blob/master/src/main/python/pybuilder/pluginloader.py#L64 triggers if the plugin has already been downloaded and then simply continues without checking for updates.

Member

esc commented Mar 10, 2016

So, the ThirdPartyPluginLoader https://github.com/pybuilder/pybuilder/blob/master/src/main/python/pybuilder/pluginloader.py#L64 triggers if the plugin has already been downloaded and then simply continues without checking for updates.

@esc

This comment has been minimized.

Show comment
Hide comment
@esc

esc Mar 10, 2016

Member

One would probably have to refactor the way in which the plugins are loaded.

You could try chaning the order in:

https://github.com/pybuilder/pybuilder/blob/master/src/main/python/pybuilder/reactor.py#L63

And put the downloading_thirdparty_plugin_loader first.

Member

esc commented Mar 10, 2016

One would probably have to refactor the way in which the plugins are loaded.

You could try chaning the order in:

https://github.com/pybuilder/pybuilder/blob/master/src/main/python/pybuilder/reactor.py#L63

And put the downloading_thirdparty_plugin_loader first.

@esc

This comment has been minimized.

Show comment
Hide comment
@esc

esc Mar 10, 2016

Member

I'll try that now locally and get back.

Member

esc commented Mar 10, 2016

I'll try that now locally and get back.

@esc

This comment has been minimized.

Show comment
Hide comment
@esc

esc Mar 10, 2016

Member

So, reversing the order of the plugin loaders AND specifying the version will update the plugin.

Member

esc commented Mar 10, 2016

So, reversing the order of the plugin loaders AND specifying the version will update the plugin.

@esc

This comment has been minimized.

Show comment
Hide comment
@esc

esc Mar 10, 2016

Member

Not sure what kind of stuff breaks when doing this, all unittests pass though.

Member

esc commented Mar 10, 2016

Not sure what kind of stuff breaks when doing this, all unittests pass though.

@mriehl

This comment has been minimized.

Show comment
Hide comment
@mriehl

mriehl Mar 10, 2016

Member

I don't think it's a problem. Running pybuilder will always cause network I/O though.
I think we could roll with this but we really need to settle on an update strategy (either requested by user as a task, so that the user can choose how to handle it with default tasks for instance, or as a clever automatism or even on a per-plugin basis).

On 10 Mar 2016, at 17:21, Valentin Haenel notifications@github.com wrote:

Not sure what kind of stuff breaks when doing this, all unittests pass though.


Reply to this email directly or view it on GitHub.

Member

mriehl commented Mar 10, 2016

I don't think it's a problem. Running pybuilder will always cause network I/O though.
I think we could roll with this but we really need to settle on an update strategy (either requested by user as a task, so that the user can choose how to handle it with default tasks for instance, or as a clever automatism or even on a per-plugin basis).

On 10 Mar 2016, at 17:21, Valentin Haenel notifications@github.com wrote:

Not sure what kind of stuff breaks when doing this, all unittests pass though.


Reply to this email directly or view it on GitHub.

@mrburrito

This comment has been minimized.

Show comment
Hide comment
@mrburrito

mrburrito Mar 10, 2016

My vote would be to automatically check for, and update outdated plugins if a fuzzy version specifier is provided. If you have a locked version, no need to check once it's installed. I think general user expectation (granted, this is from my specific viewpoint) would be that plugin updates are transparent to them once they've specified they want ~=, >=, <=, >, or < some version.

mrburrito commented Mar 10, 2016

My vote would be to automatically check for, and update outdated plugins if a fuzzy version specifier is provided. If you have a locked version, no need to check once it's installed. I think general user expectation (granted, this is from my specific viewpoint) would be that plugin updates are transparent to them once they've specified they want ~=, >=, <=, >, or < some version.

@mriehl

This comment has been minimized.

Show comment
Hide comment
@mriehl

mriehl Mar 10, 2016

Member

Yeah that sounds like intuitive behaviour. But when the automatic upgrade fails, is it an error? I don't think it should be transparent. Perhaps a warning about the failed upgrade?

On 10 Mar 2016, at 17:45, Gordon Shankman notifications@github.com wrote:

My vote would be to automatically check for, and update outdated plugins if a fuzzy version specifier is provided. If you have a locked version, no need to check once it's installed. I think general user expectation (granted, this is from my specific viewpoint) would be that plugin updates are transparent to them once they've specified they want ~=, >=, <=, >, or < some version.


Reply to this email directly or view it on GitHub.

Member

mriehl commented Mar 10, 2016

Yeah that sounds like intuitive behaviour. But when the automatic upgrade fails, is it an error? I don't think it should be transparent. Perhaps a warning about the failed upgrade?

On 10 Mar 2016, at 17:45, Gordon Shankman notifications@github.com wrote:

My vote would be to automatically check for, and update outdated plugins if a fuzzy version specifier is provided. If you have a locked version, no need to check once it's installed. I think general user expectation (granted, this is from my specific viewpoint) would be that plugin updates are transparent to them once they've specified they want ~=, >=, <=, >, or < some version.


Reply to this email directly or view it on GitHub.

@mrburrito

This comment has been minimized.

Show comment
Hide comment
@mrburrito

mrburrito Mar 10, 2016

That's a tough one. On the one hand, you might be expecting the updated version; particularly if you're doing active development on a plugin. On the other, you may not need the new version and don't want your builds failing if it can't be retrieved.

I think I lean towards failing by default with a command line option to treat those failures as a warning and continue the build. If I'm not locking down the version, I should be expecting updates when they become available.

mrburrito commented Mar 10, 2016

That's a tough one. On the one hand, you might be expecting the updated version; particularly if you're doing active development on a plugin. On the other, you may not need the new version and don't want your builds failing if it can't be retrieved.

I think I lean towards failing by default with a command line option to treat those failures as a warning and continue the build. If I'm not locking down the version, I should be expecting updates when they become available.

@esc

This comment has been minimized.

Show comment
Hide comment
@esc

esc Mar 10, 2016

Member

+1 on expecting a new version when available, it's the way we handle dependency updates too

Member

esc commented Mar 10, 2016

+1 on expecting a new version when available, it's the way we handle dependency updates too

@arcivanov arcivanov added the bug label Mar 11, 2016

@arcivanov arcivanov self-assigned this Mar 11, 2016

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Mar 15, 2016

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Mar 15, 2016

@arcivanov

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Mar 15, 2016

Contributor

Ok peeps.
ThirdpartyPluginLoader is merged with a Downloading one. The logic is now as follows:

If a plugin is "vcs:..." then force reinstall. If a plugin is "pypi:..." and version is specified and version specifier set contains at least one operator that is not "==" or "===" then update the plugin.

Try loading plugin module.

If plugin module is not loaded (which may be the case if it's a built-in third-party or PYPI plugin with no version specifier or with an exact version that has not been installed yet) then install plugin.

Try loading plugin module for the final time.

@mrburrito please try out #342.
You can do this by running pip install git+git://github.com/arcivanov/pybuilder#issue_340

@mriehl @esc please review and comment.

Contributor

arcivanov commented Mar 15, 2016

Ok peeps.
ThirdpartyPluginLoader is merged with a Downloading one. The logic is now as follows:

If a plugin is "vcs:..." then force reinstall. If a plugin is "pypi:..." and version is specified and version specifier set contains at least one operator that is not "==" or "===" then update the plugin.

Try loading plugin module.

If plugin module is not loaded (which may be the case if it's a built-in third-party or PYPI plugin with no version specifier or with an exact version that has not been installed yet) then install plugin.

Try loading plugin module for the final time.

@mrburrito please try out #342.
You can do this by running pip install git+git://github.com/arcivanov/pybuilder#issue_340

@mriehl @esc please review and comment.

@mriehl

This comment has been minimized.

Show comment
Hide comment
@mriehl

mriehl Mar 16, 2016

Member

Hmm, don't we want to update if no version is present at all?

Member

mriehl commented Mar 16, 2016

Hmm, don't we want to update if no version is present at all?

@mrburrito

This comment has been minimized.

Show comment
Hide comment
@mrburrito

mrburrito Mar 16, 2016

Still not working. I installed that patch version and I'm using the build.py file below to test. The first time I run pyb, it downloads the most recent dev build of my_plugin and executes the lver task correctly, outputting the version string of my plugin.

If I then modify that version string and upload a new dev version to my pypi repository, it fails to grab the new version and still outputs the old version string. I confirmed that a pip install --upgrade --pre my_plugin grabs the new version. The pyb upload task in my_plugin is appending the timestamp for the dev versions, so I end up with 0.4.0.dev20160316175310 and so on.

build.py

from pybuilder.core import init, use_plugin

use_plugin('python.core')
use_plugin('python.install_dependencies')
use_plugin('pypi:my_plugin', '>=0.4.0.dev')

default_task = 'lver'

mrburrito commented Mar 16, 2016

Still not working. I installed that patch version and I'm using the build.py file below to test. The first time I run pyb, it downloads the most recent dev build of my_plugin and executes the lver task correctly, outputting the version string of my plugin.

If I then modify that version string and upload a new dev version to my pypi repository, it fails to grab the new version and still outputs the old version string. I confirmed that a pip install --upgrade --pre my_plugin grabs the new version. The pyb upload task in my_plugin is appending the timestamp for the dev versions, so I end up with 0.4.0.dev20160316175310 and so on.

build.py

from pybuilder.core import init, use_plugin

use_plugin('python.core')
use_plugin('python.install_dependencies')
use_plugin('pypi:my_plugin', '>=0.4.0.dev')

default_task = 'lver'
@mrburrito

This comment has been minimized.

Show comment
Hide comment
@mrburrito

mrburrito Mar 16, 2016

I'll second @mriehl; I think you should auto-update to the latest version of a plugin unless the version is explicitly locked.

mrburrito commented Mar 16, 2016

I'll second @mriehl; I think you should auto-update to the latest version of a plugin unless the version is explicitly locked.

@arcivanov

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Mar 16, 2016

Contributor

@mrburrito could you provide a debug log of your build please? It's pretty hard to know what exactly isn't working based on "doesn't work" :)

Contributor

arcivanov commented Mar 16, 2016

@mrburrito could you provide a debug log of your build please? It's pretty hard to know what exactly isn't working based on "doesn't work" :)

@arcivanov

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Mar 16, 2016

Contributor

@mriehl @mrburrito here's the problem:

My thinking is if you specify "no version at all" it means you don't care about the version and if you have SOME version then you are already good.

If I implement this update for no version at all it means that EVERY build will go through network IO and PyPi. Do you really want that?

Contributor

arcivanov commented Mar 16, 2016

@mriehl @mrburrito here's the problem:

My thinking is if you specify "no version at all" it means you don't care about the version and if you have SOME version then you are already good.

If I implement this update for no version at all it means that EVERY build will go through network IO and PyPi. Do you really want that?

@arcivanov

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Mar 16, 2016

Contributor

Also, due to how plugin loading is implemented, it's not going to be "collect all external plugin references and install/update plugins once", it's going to be "for every plugin encountered, install/update independently", i.e number of trips is literally unbounded.

Contributor

arcivanov commented Mar 16, 2016

Also, due to how plugin loading is implemented, it's not going to be "collect all external plugin references and install/update plugins once", it's going to be "for every plugin encountered, install/update independently", i.e number of trips is literally unbounded.

@mrburrito

This comment has been minimized.

Show comment
Hide comment
@mrburrito

mrburrito Mar 16, 2016

good point. I guess from the perspective of other build tools, they typically require a version specification, which makes that check much more efficient.

mrburrito commented Mar 16, 2016

good point. I guess from the perspective of other build tools, they typically require a version specification, which makes that check much more efficient.

@arcivanov

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Mar 16, 2016

Contributor

Well, we could use pkg_resource entry-point discovery, but that will require ditching the current plugin loading system destroying backward compatibility.

Contributor

arcivanov commented Mar 16, 2016

Well, we could use pkg_resource entry-point discovery, but that will require ditching the current plugin loading system destroying backward compatibility.

@mrburrito

This comment has been minimized.

Show comment
Hide comment
@mrburrito

mrburrito Mar 16, 2016

to clarify my earlier point -- I've changed my opinion on behavior if no version is specified; not suggesting a version should be required. If there is no version, assume that any installed version is acceptable

mrburrito commented Mar 16, 2016

to clarify my earlier point -- I've changed my opinion on behavior if no version is specified; not suggesting a version should be required. If there is no version, assume that any installed version is acceptable

@arcivanov

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Mar 16, 2016

Contributor

@mrburrito cool!
Could you also provide me with pyb -X -v debug log for the build that isn't updating the plugin the way you want?

Contributor

arcivanov commented Mar 16, 2016

@mrburrito cool!
Could you also provide me with pyb -X -v debug log for the build that isn't updating the plugin the way you want?

@arcivanov

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Mar 17, 2016

Contributor

@mrburrito did you have a chance to get the debug log?

Contributor

arcivanov commented Mar 17, 2016

@mrburrito did you have a chance to get the debug log?

@mrburrito

This comment has been minimized.

Show comment
Hide comment
@mrburrito

mrburrito Mar 18, 2016

I got stuck putting out some fires at work today. I'll get the log for you
first thing tomorrow.

On Thu, Mar 17, 2016 at 6:28 PM, Arcadiy Ivanov notifications@github.com
wrote:

@mrburrito https://github.com/mrburrito did you have a chance to get
the debug log?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#340 (comment)

mrburrito commented Mar 18, 2016

I got stuck putting out some fires at work today. I'll get the log for you
first thing tomorrow.

On Thu, Mar 17, 2016 at 6:28 PM, Arcadiy Ivanov notifications@github.com
wrote:

@mrburrito https://github.com/mrburrito did you have a chance to get
the debug log?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#340 (comment)

@mrburrito

This comment has been minimized.

Show comment
Hide comment
@mrburrito

mrburrito Mar 18, 2016

Here's the log file, along with my build.py and the relevant @task from the plugin.

pybuilder_aws_lambda_plugin excerpt
VERSION = (0, 4, 0, 'dev')
__version__ = VERSION
__versionstr__ = '.'.join(map(str, VERSION))

@task
def lver(logger):
    logger.info("VERSION: {}".format(__versionstr__))
build.py
from pybuilder.core import use_plugin

use_plugin('python.core')
use_plugin('python.install_dependencies')
use_plugin('pypi:pybuilder_aws_plugin')
use_plugin('pypi:pybuilder_aws_lambda_plugin', '>=0.4.0.dev')

name = 'pyb_test'
version = '0.1.1'
default_task = 'lver'

Version of pybuilder_aws_lambda_plugin in virtualenv site-packages: 0.4.0.dev20160316175310
Versions of pybuilder_aws_lambda_plugin in pypi repository:

  • 0.4.0.dev20160310151716
  • 0.4.0.dev20160316174500
  • 0.4.0.dev20160316175220
  • 0.4.0.dev20160316175310
  • 0.4.0.dev20160316175433
  • 0.4.0.dev20160316180346
  • 0.4.0.dev20160318125108

pyb_debug.txt

mrburrito commented Mar 18, 2016

Here's the log file, along with my build.py and the relevant @task from the plugin.

pybuilder_aws_lambda_plugin excerpt
VERSION = (0, 4, 0, 'dev')
__version__ = VERSION
__versionstr__ = '.'.join(map(str, VERSION))

@task
def lver(logger):
    logger.info("VERSION: {}".format(__versionstr__))
build.py
from pybuilder.core import use_plugin

use_plugin('python.core')
use_plugin('python.install_dependencies')
use_plugin('pypi:pybuilder_aws_plugin')
use_plugin('pypi:pybuilder_aws_lambda_plugin', '>=0.4.0.dev')

name = 'pyb_test'
version = '0.1.1'
default_task = 'lver'

Version of pybuilder_aws_lambda_plugin in virtualenv site-packages: 0.4.0.dev20160316175310
Versions of pybuilder_aws_lambda_plugin in pypi repository:

  • 0.4.0.dev20160310151716
  • 0.4.0.dev20160316174500
  • 0.4.0.dev20160316175220
  • 0.4.0.dev20160316175310
  • 0.4.0.dev20160316175433
  • 0.4.0.dev20160316180346
  • 0.4.0.dev20160318125108

pyb_debug.txt

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Mar 19, 2016

@arcivanov

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Mar 19, 2016

Contributor

@mrburrito

You have an old version of the PyB it seems.

Here's what you're supposed to be getting in relevant parts:

[DEBUG] Found task 'list_dependencies' with dependencies []
[DEBUG] Registering task 'list_dependencies'
[DEBUG] Loading plugin 'pypi:pybuilder_aws_lambda_plugin' version >=0.4.0.dev
[INFO]  Downloading or updating plugin pypi:pybuilder_aws_lambda_plugin version >=0.4.0.dev
[DEBUG] Invoking pip: ['/Users/arcivanov/.pyenv/versions/3.5.1/envs/karellen-venv/bin/python3.5', '-m', 'pip.__main__', 'install', '--upgrade', 'pybuilder_aws_lambda_plugin>=0.4.0.dev']
[ERROR] The following pip error was encountered:
  Could not find a version that satisfies the requirement pybuilder-aws-lambda-plugin>=0.4.0.dev (from versions: )
No matching distribution found for pybuilder-aws-lambda-plugin>=0.4.0.dev

[ERROR] Could not install or upgrade plugin pypi:pybuilder_aws_lambda_plugin version >=0.4.0.dev: Missing plugin 'pypi:pybuilder_aws_lambda_plugin': Failed to install plugin from pybuilder_aws_lambda_plugin>=0.4.0.dev.

The build branch would not call built-in loader if there are : in the name of the plugin. Yet your log indicates this:

[DEBUG] Trying to load builtin plugin 'pypi:pybuilder_aws_lambda_plugin'
[DEBUG] Trying to load third party plugin 'pybuilder_aws_lambda_plugin'
[DEBUG] Found third party plugin 'pybuilder_aws_lambda_plugin'

UPD: I know what the problem is - I gave you an update pip command with wrong syntax. Sorry!

pip install --upgrade git+git://github.com/arcivanov/pybuilder@issue_340

Branch is separated with an @ and not # 😭

UPD 2: The latest branch push simply added "or updating" to the log message.

Contributor

arcivanov commented Mar 19, 2016

@mrburrito

You have an old version of the PyB it seems.

Here's what you're supposed to be getting in relevant parts:

[DEBUG] Found task 'list_dependencies' with dependencies []
[DEBUG] Registering task 'list_dependencies'
[DEBUG] Loading plugin 'pypi:pybuilder_aws_lambda_plugin' version >=0.4.0.dev
[INFO]  Downloading or updating plugin pypi:pybuilder_aws_lambda_plugin version >=0.4.0.dev
[DEBUG] Invoking pip: ['/Users/arcivanov/.pyenv/versions/3.5.1/envs/karellen-venv/bin/python3.5', '-m', 'pip.__main__', 'install', '--upgrade', 'pybuilder_aws_lambda_plugin>=0.4.0.dev']
[ERROR] The following pip error was encountered:
  Could not find a version that satisfies the requirement pybuilder-aws-lambda-plugin>=0.4.0.dev (from versions: )
No matching distribution found for pybuilder-aws-lambda-plugin>=0.4.0.dev

[ERROR] Could not install or upgrade plugin pypi:pybuilder_aws_lambda_plugin version >=0.4.0.dev: Missing plugin 'pypi:pybuilder_aws_lambda_plugin': Failed to install plugin from pybuilder_aws_lambda_plugin>=0.4.0.dev.

The build branch would not call built-in loader if there are : in the name of the plugin. Yet your log indicates this:

[DEBUG] Trying to load builtin plugin 'pypi:pybuilder_aws_lambda_plugin'
[DEBUG] Trying to load third party plugin 'pybuilder_aws_lambda_plugin'
[DEBUG] Found third party plugin 'pybuilder_aws_lambda_plugin'

UPD: I know what the problem is - I gave you an update pip command with wrong syntax. Sorry!

pip install --upgrade git+git://github.com/arcivanov/pybuilder@issue_340

Branch is separated with an @ and not # 😭

UPD 2: The latest branch push simply added "or updating" to the log message.

@mrburrito

This comment has been minimized.

Show comment
Hide comment
@mrburrito

mrburrito Mar 21, 2016

That worked! It updates correctly now, at least for the dev versions. Thanks!

mrburrito commented Mar 21, 2016

That worked! It updates correctly now, at least for the dev versions. Thanks!

@arcivanov

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Mar 21, 2016

Contributor

I'll merge as soon as @mriehl reviews

Contributor

arcivanov commented Mar 21, 2016

I'll merge as soon as @mriehl reviews

@mriehl

This comment has been minimized.

Show comment
Hide comment
@mriehl

mriehl Mar 22, 2016

Member

Done. Already reviewed a few days ago, but was waiting to see if it solves the issue author's problem ;)

On 21 Mar 2016, at 17:58, Arcadiy Ivanov notifications@github.com wrote:

I'll merge as soon as @mriehl reviews


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

Member

mriehl commented Mar 22, 2016

Done. Already reviewed a few days ago, but was waiting to see if it solves the issue author's problem ;)

On 21 Mar 2016, at 17:58, Arcadiy Ivanov notifications@github.com wrote:

I'll merge as soon as @mriehl reviews


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@arcivanov arcivanov closed this in #342 Mar 22, 2016

@arcivanov arcivanov removed the in progress label Mar 22, 2016

@esc

This comment has been minimized.

Show comment
Hide comment
@esc

esc Mar 24, 2016

Member

Thanks for all the hard work.

Member

esc commented Mar 24, 2016

Thanks for all the hard work.

@mriehl

This comment has been minimized.

Show comment
Hide comment
@mriehl

mriehl Mar 24, 2016

Member

@mrburrito released with 0.11.8.

Member

mriehl commented Mar 24, 2016

@mrburrito released with 0.11.8.

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Apr 8, 2016

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Apr 8, 2016

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Apr 10, 2016

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Apr 11, 2016

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Apr 11, 2016

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Apr 11, 2016

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Apr 11, 2016

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Apr 11, 2016

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Apr 11, 2016

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Apr 12, 2016

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Apr 15, 2016

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Apr 15, 2016

arcivanov added a commit that referenced this issue Apr 15, 2016

Merge pull request #347 from arcivanov/issue_346
PyBuilder install_dependencies behavior should mirror #340
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment