Skip to content
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

Better handling of chalicelib #299

Open
colde opened this issue Apr 20, 2017 · 7 comments
Open

Better handling of chalicelib #299

colde opened this issue Apr 20, 2017 · 7 comments

Comments

@colde
Copy link

colde commented Apr 20, 2017

I would like to suggest that chalice does an automatic sys.path.append of the chalicelib directory, both when running chalice local, and when actually running lambda.

This would make it easier to use with very little drawbacks.

Also, the documentation should probably mention the use of chalicelib as well.

@nedlowe
Copy link

nedlowe commented Apr 21, 2017

The Github page doesn't mention chalicelib, but the full documentation does:

http://chalice.readthedocs.io/en/latest/topics/packaging.html

@jamesls
Copy link
Member

jamesls commented May 2, 2017

Is the suggestion to add chalice to sys.path so you don't have to have chalicelib in your imports?

So instead of from chalicelib import mymodule you could just say import mymodule?

@colde
Copy link
Author

colde commented May 3, 2017

@jamesls Yeah, that is indeed it. Maybe also some clarification between what should go in chalicelib, and what should go in vendor.

@nedlowe
Copy link

nedlowe commented May 3, 2017

I disagree, the chalicelib folder should be explicitly referenced (although perhaps it shouldn't have to be called chalicelib, but that's a separate question).

chalicelib is for organising one's own code. vendor is for third-party builds of software that needs to be made available in your Chalice project. For pure-Python projects on PyPI that is unnecessary, but for:

  1. Projects not on PyPI
  2. Non-pure Python projects that need to be built

then they need to be uploaded via vendor.

E.g. https://github.com/amaas-fintech/chalice-vendor-packages - is a package that needs to be compiled into a .so file. When running locally, the package is picked up from my local pip install, but on Chalice it is referenced from the vendor folder - so it works from both (the lambda compliant build obviously wouldn't work locally).

@charlie0077
Copy link

"from chalicelib import mymodule you could just say import mymodule"

I just spent 40 min trying to figure out why "import mymodule" failed.
Better to mention chalicelib in github readme.

@sbraverman
Copy link

When working locally, I've found that my custom python files work just fine regardless of directory structure.

I too spent a lithe bit of time trying to figure out how deployed chalice app can utilize my custom python files (finally found chalicelib in docs).

I created the following pr, does it help?
#496

@hannes-ucsc
Copy link

This looks to me like a design flaw. Conceptually, chalicelib is similar to the site-packages directory found in most Python distributions. It is not a top-level package by itself, it is the root of a package hierarchy, a directory containing top-level packages, a directory whose path occurs on sys.path.

This may work for the simplest use case, one lambda function per project, but as soon as you move to more complex projects, ones with more than one lambda, or ones that are deployed in other ways, not just as a lambda function having every package start with chalicelib is plain odd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants