Quoting Eli Schwartz via aur-general (2018-11-15 00:52:50)
On 11/14/18 11:50 PM, Daniel M. Capella via aur-general wrote:
Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
- tests are awesome <3 run them whenever possible! more is better! pulling sources from github is favorable when you get free tests and sometimes manpages/docs
Will work with the upstreams to distribute these. I prefer to use published offerings as they are what the authors intend to be used. GitHub autogenerated tarballs are also subject to change: https://marc.info/?l=openbsd-ports&m=151973450514279&w=2
I've seen the occasional *claim* that this happens, but I've yet to see any actual case where this happens and it isn't because of upstream force-pushing a tag.
GitHub is supposed to use git-archive(1) for this, which is guaranteed to be reproducible when generating .tar, although in theory post-filtering this through a compressor like gzip can result in changes from one version of git to another. I say in theory because I don't recall this ever happening, and git-archive uses the fairly boring defaults.
I don't see any reason to use substandard sources in order to avoid checksum problems I don't believe in.
"substandard" 🤔 https://wiki.archlinux.org/index.php/Python_package_guidelines#Source
For Rust sources there's also this problem: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-v...
Crates explicitly filter out lock files. `publish-lockfile` for binary crates is still only available in Cargo nightly. Communication is already in progress with the relevant upstreams.
I have no clue what this is even supposed to mean. I'm reading your link and it says that "it's conventional" for upstream developers of rust applications to commit their lockfiles to git, but not to do so for libraries. Given that one builds applications, and not libraries, I'm unsure what the problem is here.
Do you mean to say that crates.io doesn't ship all the files available in git? Okay, I agree that git is the superior source. I don't generally trust "intelligent" tools to decide what's important.
Still not sure what this doc describing the split between libraries and binaries, has to do with anything.
https://github.com/bluejekyll/trust-dns/issues/604#issuecomment-436510626
python-soco: - there are tests available for check() via py.test
Requires jumping through hoops. See the note: https://soco.readthedocs.io/en/latest/development/unittests.html?highlight=t...
Sounds like they have two sets of tests: some unittests for the code correctness, plus unittests to test the interaction with an online server.
Also sounds like the former, which are all we care about I suppose, should be easy to do without any hoops, just by running pytest?
Yeah, I tried that.
- do we _really_ need to split razer mouse tool UI and daemon here? doubt it tbh.
The UI is completely optional. ¯\_(ツ)_/¯
Why does this mean they cannot be a single package?
-- Eli Schwartz Bug Wrangler and Trusted User
-- Best, polyzen