4 ms·

Zip files in the repo? Looks odd to me.

by ben174 11y ago

minimaxir 11y ago
Git and the Service files do not play well, so I have to Zip the files first.
- curun1r 11y ago
  There are two XML files and a PNG file in the one zip I looked into...why doesn't that work with git? Incidentally, there's also a bunch of extra Dropbox files that you probably don't want to be including. It looks like you developed this on a Mac, saved it to Dropbox and then created the Zip on a Windows box. Sorry to say it, but the whole thing feels like an amateurish wrapper around: pbpaste | /usr/local/bin/pygmentize -g -O style=... -f rtf -l ... | pbcopy which appears to do all the work.
  - minimaxir 11y ago
    Since the services are not a single file, it is not user-friendly to download directly from the Repo if the files are not zipped. The tool is essentially a wrapper. I do not deny that in the credits. However, there's nothing wrong with that. It's simple, yes, but it does what it promises. (Additionally, it still took a couple hours in QA and README presentation) There shouldn't be Dropbox metadata though. I'll double-check that.
    - curun1r 11y ago
      > Since the services are not a single file, it is not user-friendly to download directly from the Repo if the files are not zipped. I think you're conflating two separate things, source code and a packaged releases. The Github repository should have the source code, which in your case is the XML code for the workflow and plist. You then create a release [1] from that software. It's usually customary to include the script used to build it, which in this case is likely just a shell script wrapper around the zip command to create the archive. The important point is that the source is always visible. Uploading zip files into the repo gives the impression that you're trying to hide something, even if that isn't the case. Also, one of the great things about open source is that people can be curious. It's likely that if you had checked in the unzipped files, people would have browsed through them in the Github UI to see how it worked. Fewer people will take the time to clone the repo or download/unzip/browse the zip file. [1] https://github.com/blog/1547-release-your-software https://github.com/blog/1547-release-your-software

Zip files in the repo? Looks odd to me.

by ben174 11y ago

Zip files in the repo? Looks odd to me.

minimaxir 11y ago

Git and the Service files do not play well, so I have to Zip the files first.

curun1r 11y ago
There are two XML files and a PNG file in the one zip I looked into...why doesn't that work with git? Incidentally, there's also a bunch of extra Dropbox files that you probably don't want to be including. It looks like you developed this on a Mac, saved it to Dropbox and then created the Zip on a Windows box. Sorry to say it, but the whole thing feels like an amateurish wrapper around: pbpaste | /usr/local/bin/pygmentize -g -O style=... -f rtf -l ... | pbcopy which appears to do all the work.
- minimaxir 11y ago
  Since the services are not a single file, it is not user-friendly to download directly from the Repo if the files are not zipped. The tool is essentially a wrapper. I do not deny that in the credits. However, there's nothing wrong with that. It's simple, yes, but it does what it promises. (Additionally, it still took a couple hours in QA and README presentation) There shouldn't be Dropbox metadata though. I'll double-check that.
  - curun1r 11y ago
    > Since the services are not a single file, it is not user-friendly to download directly from the Repo if the files are not zipped. I think you're conflating two separate things, source code and a packaged releases. The Github repository should have the source code, which in your case is the XML code for the workflow and plist. You then create a release [1] from that software. It's usually customary to include the script used to build it, which in this case is likely just a shell script wrapper around the zip command to create the archive. The important point is that the source is always visible. Uploading zip files into the repo gives the impression that you're trying to hide something, even if that isn't the case. Also, one of the great things about open source is that people can be curious. It's likely that if you had checked in the unzipped files, people would have browsed through them in the Github UI to see how it worked. Fewer people will take the time to clone the repo or download/unzip/browse the zip file. [1] https://github.com/blog/1547-release-your-software https://github.com/blog/1547-release-your-software