Scoop: Separate main bucket from scoop code?

Created on 11 Feb 2017  ยท  5Comments  ยท  Source: lukesampson/scoop

Changes to manifests are for the most part unrelated to changes to the core scoop codebase. To reduce overlap, we could move the bucket/ directory into its own repository. Thoughts?

question

Most helpful comment

Core extraction should be easy task to do and should not take too long. But there is one big question.

How to deal with bucket being in other repository?

There are 3 main options. Submodule / Subtree and actual known bucket flow.

  1. Known bucket flow would be most familiar to users

    • It would require few code tweaks.



      • Replace hardcoded bucket path


      • scoop update / checkup to reflect change and no need for users to do anything.


      • It would allow user to install from main bucket using main/manifest syntax, which is not possible right now



  2. Submodule / Subtree

    • Easiest method, with single config file, but I don't know, how would this affect users.

Extraction process

  1. [x] Postpone Excavator
  2. [x] Binaries

    • Remove default dir parameter

  3. [x] lib
  4. [x] How to deal with bucket?

    1. Same as other known buckets



      1. [x] Add first known bucket





        1. [x] "main": "ScoopInstaller/MainBucket"





      2. [x] On installing add main bucket


      3. [x] On scoop update # Compatibility check





        1. [x] Check for already added main bucket







          1. [ ] If it's not added, add









      4. [x] scoop checkup should check for main bucket



    2. git submodule

    3. git subtree

  5. [x] Extract bucket into custom repository

    1. [x] Create new repo ScoopInstaller/MainBucket

    2. [x] Extract bucket folder from core repository



      1. [x] https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/



    3. [x] Binaries

    4. [x] Run formatjson on all manifests

    5. [x] Readme

    6. [x] Appveyor

  6. [x] Change excavator config with new repository
  7. [x] Start excavator again
  8. [ ] Move issues (manifest requests) into main bucket repo
  9. [ ] โ“ Rename this bucket into Core or something
  10. [ ] โ“ Move it to same organization
  11. [ ] ๐ŸŽ‰๐ŸŽ‰ Welcome new era of Scoop with easier maintaining and expanding ๐ŸŽ‰๐ŸŽ‰

Let me know, if I missed something.

All 5 comments

It would be tidier I suppose. Is it causing problems the way it is though? It might even slow scoop update down if we have to do two git pulls rather than two. There doesn't seem to be a big benefit to justify changing it just yet.

Wondered about this as well. The way it is at the moment, it's cumbersome to run scoop from a working copy of your own fork, since you have to keep pulling in changes manually, just to keep the main bucket up to date.

Edit: Another issue I guess is that the commit log is rather hard to read because of all the bucket & update-related commits. I don't know if slowing scoop update down a bit is really an issue, especially since it also has to update scoop-extras & any other buckets anyway.

And we could sub-module the bucket directory, if we wanted. We could even design it to allow users to sub-module any other buckets they wanted, eliminating the need for scoop bucket add

+1 it would be better so if you watch the scoop github repository you don't have notifications about packages, only the app itself ;)

Core extraction should be easy task to do and should not take too long. But there is one big question.

How to deal with bucket being in other repository?

There are 3 main options. Submodule / Subtree and actual known bucket flow.

  1. Known bucket flow would be most familiar to users

    • It would require few code tweaks.



      • Replace hardcoded bucket path


      • scoop update / checkup to reflect change and no need for users to do anything.


      • It would allow user to install from main bucket using main/manifest syntax, which is not possible right now



  2. Submodule / Subtree

    • Easiest method, with single config file, but I don't know, how would this affect users.

Extraction process

  1. [x] Postpone Excavator
  2. [x] Binaries

    • Remove default dir parameter

  3. [x] lib
  4. [x] How to deal with bucket?

    1. Same as other known buckets



      1. [x] Add first known bucket





        1. [x] "main": "ScoopInstaller/MainBucket"





      2. [x] On installing add main bucket


      3. [x] On scoop update # Compatibility check





        1. [x] Check for already added main bucket







          1. [ ] If it's not added, add









      4. [x] scoop checkup should check for main bucket



    2. git submodule

    3. git subtree

  5. [x] Extract bucket into custom repository

    1. [x] Create new repo ScoopInstaller/MainBucket

    2. [x] Extract bucket folder from core repository



      1. [x] https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/



    3. [x] Binaries

    4. [x] Run formatjson on all manifests

    5. [x] Readme

    6. [x] Appveyor

  6. [x] Change excavator config with new repository
  7. [x] Start excavator again
  8. [ ] Move issues (manifest requests) into main bucket repo
  9. [ ] โ“ Rename this bucket into Core or something
  10. [ ] โ“ Move it to same organization
  11. [ ] ๐ŸŽ‰๐ŸŽ‰ Welcome new era of Scoop with easier maintaining and expanding ๐ŸŽ‰๐ŸŽ‰

Let me know, if I missed something.

Was this page helpful?
0 / 5 - 0 ratings