-
Notifications
You must be signed in to change notification settings - Fork 2
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
[joss][package structure][nice to have] Refactor into src
-like directory structure?
#21
Comments
src
-like directoy structure?src
-like directory structure?
Thank you for pointing this out and your suggestion. We were actually happy to do this at first, but then we realised it is maybe better in our case to keep it this way, and should not be too problematic? |
ooh yes! this is another thing that the webpack stuff can help with - since gh pages are just gh actions now, you can make an action that builds the site to a branch and then deploys from there so you have more control over the structure of your source directory.
most definitely a higher priority!!!! this was mostly just a "would this be nice for y'all?" issue, so no worries about keeping it this way. here's a super trivial example of building something with sphinx and deploying to gh pages - https://github.com/p2p-ld/docs/blob/main/.github/workflows/sphinx.yml yours would be even simpler since it's ready-to-roll JS name: Deploy
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
contents: write # To push a branch
steps:
- uses: actions/checkout@v3
- name: deploy to gh-pages
uses: JamesIves/github-pages-deploy-action@v4
with:
folder: src but again only do that if it's easier for you to tend to your code! |
Thank you very much @sneakers-the-rat . This sounds good. For the moment, we would like to keep things as they are, and once we will look into the PR that you so kindly drafted for starting the packaging, moving to actions here will become interesting. |
Up to you, feel free to close this if youd like. |
Part of: openjournals/joss-reviews#6336
Not a requirement of the review, but a nice-to-have:
Currently the project is structured s.t. the public assets/pages/etc. are in the same top-level directory as the tests and package metadata. Would be nice to make a clearer distinction between what is intended to be deployed on a web server/run locally vs. what is intended to be used as support. this is partially cosmetic, but would also be important for extensibility/maintainability later, as eg. adding more test cases that an http server would be serving could be undesirable if they exposed some vulnerability to the host machine.
So that would look something like
The text was updated successfully, but these errors were encountered: