-
Notifications
You must be signed in to change notification settings - Fork 9
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
use GitHub Actions for CI #26
Comments
Thanks @NickleDave I agree GitHub actions > Azure at present! |
@NickleDave you're right. nowadays muchos han migrado de azure pipelines para github actions (including me :) ) |
oh yea. actions are so nice for windows-mac-linux. i'm using them now on all of our packages. including earthpy and abc-classroom. just a note that i have a few reservations about poetry. it seems to be very pip focused. i need to revisit our cookie cutter again but pip and conda do not place nicely together. And for some applications (SPATIAL!!) pip is not optimal given GDAL conflicts. so we need to think carefully about what best practice recommendations look like. i may also be wrong about poetry but that was my first take when i looked at it. i've slowly been moving towards conda and conda-lock to lock environment builds . very open to any and all feedback here and to build upon the great work that @ttimbers has done!! |
Tagging @TomasBeuzen here because he has more experience than I do mixing poetry with conda. AFAIK from my discussions with him, the two do play well together, and we plan to better explain that in our book. @TomasBeuzen - can you elaborate a bit here on your experiences mixing poetry with conda? And any cons/challenges in doing so? |
I'm a bit convoluted in my workflow. I use |
Ah, I see. I think I misunderstood what you told me before Tom! |
Just to be clear - |
thank you all for this. it will be great to sort this all out! even mixing conda forge and defaults can cause conflicts so i'm just sensitive to those pain points! i do hope to find some time to play with poetry to better understand what it offers! (and to revisit our cookie cutter as well! And i seriously appreciate everyone's input here - thank you!! keep the discussion and suggestions coming! |
My usage lines up with @TomasBeuzen -- I use I use I for sure agree that there are both pros and cons to every tool and I definitely don't mean to suggest we should impose I just really like how easy it can be for pure Python packages and I bet that captures a lot of use cases, especially for devs that we want to support. Like, if I'm writing a wrapper for an API, I can just use That's why I like the book from @ttimbers and @TomasBeuzen ... an advantage might be making it as easy as possible to get started for as many people as possible, without having to worry about the 12 different ways to package a Python library. As for cons ... witness some of my interactions with the I was excited to learn from one of the maintainers that we will soon be able to declare metadata in a "tool neutral" section in pyrproject.toml files:
|
as mentioned here the UCB-MDS cookiecutter does this so we could adapt / integrate with theirs
#25 (comment)
@xmnlab and @mbjoseph discussed Azure Pipelines in #13 but my impression is that GitHub Actions is a million times easier to use, especially for newbies (and people like me who aren't so newbie but do not want to spent their whole lives thinking about CI pipelines)
The text was updated successfully, but these errors were encountered: