Re: [R-pkg-devel] Working with R-devel
On 24.01.2018 03:20, Dirk Eddelbuettel wrote: I am going in circles here and have lost my way. I used to have means to build R-devel (still do) and use it for local testing (no longer do). - Fresh build of R-devel - One entry in .libPaths() - I can install Rcpp, it ends up in that .libPaths() - I can load - With the _exact same settings_ starting R as R CMD check ... I fail on ** preparing package for lazy loading Error : package ‘Rcpp’ was installed by an R version with different internals; \ it needs to be reinstalled for use with this R version I guess you actually pick up anotehr version of R. Carefully check what is on your PATH and perhaps some Renviron files that may be around? Best, Uwe which is both false (see above) and irritating. Does anybody have any tips, working guidelines or interpretations of the ever changing manuals (which charmingly never document what changes) ? Dirk __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Working with R-devel
> Uwe Ligges > on Wed, 24 Jan 2018 11:23:50 +0100 writes: > On 24.01.2018 03:20, Dirk Eddelbuettel wrote: >> >> I am going in circles here and have lost my way. I used to have means to >> build R-devel (still do) and use it for local testing (no longer do). >> >> - Fresh build of R-devel >> - One entry in .libPaths() >> - I can install Rcpp, it ends up in that .libPaths() >> - I can load >> - With the _exact same settings_ starting R as R CMD check ... I fail on >> >> ** preparing package for lazy loading >> Error : package ‘Rcpp’ was installed by an R version with different internals; \ >> it needs to be reinstalled for use with this R version > I guess you actually pick up anotehr version of R. > Carefully check what is on your PATH and perhaps some Renviron files > that may be around? > Best, > Uwe Yes exactly. I've been bitten many times by similar issues in recent weeks. The problem here is that we have so many environment variables governing the process. I think I have mostly solved this by the following "strategy" (Linux/Unixy bash-like shell): -- ## To check: one of env | grep '^R_' env | grep -E '^_?R_' ## Before running: unset R_PROFILE R_ENVIRON R_LIBS export R_CHECK_ENVIRON=~/.R/check.Renviron_Rdevel ## where my check.Renviron* basically only sets R_LIBS - [In an ideal world, R functions involved here would *not* start other R processes... but that seems necessary for other good reasons] Martin >> >> which is both false (see above) and irritating. >> >> Does anybody have any tips, working guidelines or interpretations of the ever >> changing manuals (which charmingly never document what changes) ? >> >> Dirk >> > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] new package? - Sports data from transfermarkt.com using rvest
Dear Daniel, First of all you need to make sure that the licence of transfermarkt.com allows the usage that you have intended. If that is not clear from their website, then you should contact them rather than us. CRAN has several packages to assists in downloading data from online sources. But the source has to allow that kind of usage. Best regards, ir. Thierry Onkelinx Statisticus / Statistician Vlaamse Overheid / Government of Flanders INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND FOREST Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance thierry.onkel...@inbo.be Havenlaan 88 bus 73, 1000 Brussel www.inbo.be /// To call in the statistician after the experiment is done may be no more than asking him to perform a post-mortem examination: he may be able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger Brinner The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data. ~ John Tukey /// 2018-01-23 16:27 GMT+01:00 Kehl Dániel : > Dear List members, > > maybe this is not the right place to ask, if that is the case, please forward > me to the right place. > I developed some functions to download and transform football/soccer related > data from transfermarkt.com. > There are plans to create my first package based on these functions and of > course develop them and add more later. As far as I know there is no API to > that page, so I am using the rvest package. > My question is: is this an OK thing to do? Should I contact > transfermarkt.com? My german is not perfect (just like my english), this is > what I've found on thier webpage. Does that mean one can not create a package > related to that page? Or can't crawl at all? Or just not allowed to sell the > data? If it is allowed, can one post the package on CRAN at the end? > > Please if any of you have experience in that or just show me where to ask, do > not hesitate! > > LEGAL NOTICE > © Transfermarkt GmbH & Co. KG 2000-2018 > > All rights reserved. > > Der Inhalt dieser Website ist urheberrechtlich geschützt. Nachdruck, Aufnahme > in Online-Dienste, Internet und Vervielfältigung auf Datenträger wie CD-ROM, > DVD-ROM usw. dürfen, auch auszugsweise, nur nach vorheriger schriftlicher > Zustimmung durch Transfermarkt erfolgen. Eine kommerzielle Weitervermarktung > des Inhalts ist untersagt. > > Transfermarkt haftet nicht für unverlangt eingesandte Inhalte, Manuskripte > und Fotos. Für Inhalte externer Links und fremde Inhalte übernimmt > Transfermarkt keine Verantwortung. > > Thank you for all your insights and/or comments, > > best regards > Daniel > > > > > > > > > > > > > > > > > > > > > > Dr. KEHL Dániel > > adjunktus > > > > > > PÉCSI TUDOMÁNYEGYETEM KÖZGAZDASÁGTUDOMÁNYI KAR > > Közgazdaságtan és Ökonometria Intézet > > H-7622 Pécs, Rákóczi út 80. | www.ktk.pte.hu > > +36 72 501 599/ 23144 | ke...@ktk.pte.hu > > > > > > > > > > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Working with R-devel
On 24.01.2018 12:00, Martin Maechler wrote: Uwe Ligges on Wed, 24 Jan 2018 11:23:50 +0100 writes: > On 24.01.2018 03:20, Dirk Eddelbuettel wrote: >> >> I am going in circles here and have lost my way. I used to have means to >> build R-devel (still do) and use it for local testing (no longer do). >> >> - Fresh build of R-devel >> - One entry in .libPaths() >> - I can install Rcpp, it ends up in that .libPaths() >> - I can load >> - With the _exact same settings_ starting R as R CMD check ... I fail on >> >> ** preparing package for lazy loading >> Error : package ‘Rcpp’ was installed by an R version with different internals; \ >> it needs to be reinstalled for use with this R version > I guess you actually pick up anotehr version of R. > Carefully check what is on your PATH and perhaps some Renviron files > that may be around? > Best, > Uwe Yes exactly. I've been bitten many times by similar issues in recent weeks. The problem here is that we have so many environment variables governing the process. I think I have mostly solved this by the following "strategy" (Linux/Unixy bash-like shell): -- ## To check: one of env | grep '^R_' env | grep -E '^_?R_' ## Before running: unset R_PROFILE R_ENVIRON R_LIBS export R_CHECK_ENVIRON=~/.R/check.Renviron_Rdevel ## where my check.Renviron* basically only sets R_LIBS - [In an ideal world, R functions involved here would *not* start other R processes... but that seems necessary for other good reasons] The simplest one is that R can crash during a check, then you would end uo without message where that happened, it is hard to compare timings etc. In the real but not so ideal world, I need even a wrapper around R CMD check to have control about the process to be able to kill it programmaically etc. Best, Uwe Martin >> >> which is both false (see above) and irritating. >> >> Does anybody have any tips, working guidelines or interpretations of the ever >> changing manuals (which charmingly never document what changes) ? >> >> Dirk >> > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Working with R-devel
On 24 January 2018 at 12:00, Martin Maechler wrote: | > Uwe Ligges | > I guess you actually pick up anotehr version of R. | > Carefully check what is on your PATH and perhaps some Renviron files | > that may be around? I did, a million times, hence the frustration. | Yes exactly. I've been bitten many times by similar issues in | recent weeks. | | The problem here is that we have so many environment variables | governing the process. | I think I have mostly solved this by the following "strategy" | (Linux/Unixy bash-like shell): That looks good. I do have ~/.R/check.Renviron which likely gets in the way. I even tries to (easily) escape from that via Docker but then the most recent r-devel build on Docker blew up over something with DATAPTR (uggh). | -- | | ## To check: one of | env | grep '^R_' | env | grep -E '^_?R_' | | ## Before running: | unset R_PROFILE R_ENVIRON R_LIBS | export R_CHECK_ENVIRON=~/.R/check.Renviron_Rdevel | | ## where my check.Renviron* basically only sets R_LIBS | - The unset trick is good. That may do it. | [In an ideal world, R functions involved here would *not* start | other R processes... but that seems necessary for other good reasons] Right. Thanks for the help, gentlemen! Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] FIXED -- Working with R-devel
Thanks to Martin, my 'RD' script now points to ~/.R/check.Renviron-Rdevel in which I also set (or re-set) R_LIBS="/usr/local/lib/R-devel/site-library/" after having added this (for good measure) to my 'RD' script: unset R_PROFILE R_RENVIRON R_LIBS export R_CHECK_ENVIRON=~/.R/check.Renviron-Rdevel as suggested by Martin. I tend not to have R_PROFILE or R_ENVIRON because I find environment variable harder to control (my choice is direct settings in $RHOME/etc/Rprofile.site or $RHOME/etc/Renviron.site) but here the switch to R_LIBS did me in. Thanks again for the hint! Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Working with R-devel
On Wed, 24 Jan 2018, Uwe Ligges wrote: On 24.01.2018 12:00, Martin Maechler wrote: Uwe Ligges on Wed, 24 Jan 2018 11:23:50 +0100 writes: > On 24.01.2018 03:20, Dirk Eddelbuettel wrote: >> >> I am going in circles here and have lost my way. I used to have means to >> build R-devel (still do) and use it for local testing (no longer do). >> >> - Fresh build of R-devel >> - One entry in .libPaths() >> - I can install Rcpp, it ends up in that .libPaths() >> - I can load >> - With the _exact same settings_ starting R as R CMD check ... I fail on >> >> ** preparing package for lazy loading >> Error : package ‘Rcpp’ was installed by an R version with different internals; \ >> it needs to be reinstalled for use with this R version If you are picking up an R 3.4.x that is trying to load a package built by R-devel you should also see a warning that the package was built under R version 3.5.0 If you are not, then you could be picking up an older R-devel from before the internals change. Probably more likely, the Rcpp being loaded at that point was built by 3.4.x, which would suggest library path settings are messed up at that point, but not clear why. [It might be possible and useful to provide more information about the broken pieces in the error message but I won't have time to look any time soon.] At the moment when it matters I usually use env R_LIBS= R CMD check ... for checks under R_devel Best, luke > I guess you actually pick up anotehr version of R. > Carefully check what is on your PATH and perhaps some Renviron files > that may be around? > Best, > Uwe Yes exactly. I've been bitten many times by similar issues in recent weeks. The problem here is that we have so many environment variables governing the process. I think I have mostly solved this by the following "strategy" (Linux/Unixy bash-like shell): -- ## To check: one of env | grep '^R_' env | grep -E '^_?R_' ## Before running: unset R_PROFILE R_ENVIRON R_LIBS export R_CHECK_ENVIRON=~/.R/check.Renviron_Rdevel ## where my check.Renviron* basically only sets R_LIBS - [In an ideal world, R functions involved here would *not* start other R processes... but that seems necessary for other good reasons] The simplest one is that R can crash during a check, then you would end uo without message where that happened, it is hard to compare timings etc. In the real but not so ideal world, I need even a wrapper around R CMD check to have control about the process to be able to kill it programmaically etc. Best, Uwe Martin >> >> which is both false (see above) and irritating. >> >> Does anybody have any tips, working guidelines or interpretations of the ever >> changing manuals (which charmingly never document what changes) ? >> >> Dirk >> > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Is it ever appropriate (or mandatory) to Suggests: R (>= version) ?
I believe it is a requirement that if package A imports package B, and
package B lists package C in Depends: then package A must also list
package C in Depends:
A popular stackoverflow answer states this.[1] I can't find any other
source but it makes sense.
What if package B is suggested by package A and package B depends on a
certain version of R? That is if package A *suggests* package B and
package B lists Depends: R (>= ver). In such a case, is it necessary
to list this dependency in Suggests? Certainly endnote 12 of WRE says
it would be necessary if the dependency were for a package, but
doesn't seem to mention similar dependencies on R version. And, as far
as I can see, no package on CRAN lists R in Suggests, so it would to
be non-standard if not prohibited.
S <- available.packages()
S[grepl("(?https://stackoverflow.com/a/8638902/1664978
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Working with R-devel
On 24 January 2018 at 07:03, luke-tier...@uiowa.edu wrote: | If you are picking up an R 3.4.x that is trying to load a package | built by R-devel you should also see a warning that the package was | built under R version 3.5.0 Yes, I am of course very aware of the issue. But we had to separate out R-release and R-devel for years, and so I did. I had separate libPaths (or, at least, leading component) for R-devel because of that. | If you are not, then you could be picking up an older R-devel from | before the internals change. Probably more likely, the Rcpp being | loaded at that point was built by 3.4.x, which would suggest library | path settings are messed up at that point, but not clear why. [It | might be possible and useful to provide more information about the | broken pieces in the error message but I won't have time to look any | time soon.] | | At the moment when it matters I usually use | | env R_LIBS= R CMD check ... | | for checks under R_devel It was the R_LIBS_USER (which used to work) to R_LIBS change that got plus the fact that my R-devel was picking up my R-release check.Renviron. The hint from Martin got rid of that. Sometimes I wonder if we should have an extra-verbose mode that picks up EVERY single Sys.getenv() and alike to make it easier to trace this. But run-time cost of the check is probably unattractive. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Is it ever appropriate (or mandatory) to Suggests: R (>= version) ?
This is implicitly OK:
If A suggests B and B depends on some R version, then B is only
available if you are running that R version anyway, hence the additional
declaration is not needed.
The typical cause of trouble is as follows:
A depends on B and B suggests C.
Then A has to suggest C in case spme functionality in A relies on parts
of B that actually need C.
Best,
Uwe Ligges
On 24.01.2018 14:44, Hugh Parsonage wrote:
I believe it is a requirement that if package A imports package B, and
package B lists package C in Depends: then package A must also list
package C in Depends:
A popular stackoverflow answer states this.[1] I can't find any other
source but it makes sense.
What if package B is suggested by package A and package B depends on a
certain version of R? That is if package A *suggests* package B and
package B lists Depends: R (>= ver). In such a case, is it necessary
to list this dependency in Suggests? Certainly endnote 12 of WRE says
it would be necessary if the dependency were for a package, but
doesn't seem to mention similar dependencies on R version. And, as far
as I can see, no package on CRAN lists R in Suggests, so it would to
be non-standard if not prohibited.
S <- available.packages()
S[grepl("(?https://stackoverflow.com/a/8638902/1664978
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Is it ever appropriate (or mandatory) to Suggests: R (>= version) ?
The advice at the link you cite ([1]
https://stackoverflow.com/a/8638902/1664978) is not quite right:
> I believe it is a requirement that if package A imports package B, and
> package B lists package C in Depends: then package A must also list
> package C in Depends:
> A popular stackoverflow answer states this.[1] I can't find any other
> source but it makes sense.
You don't need (and in general should not) put a package in Depends only
because some of your imports do. In some cases you may have to, but this is
only because of missing imports in the package you import. Note that even if
the package you import (package B) "Depends" on package "C", "B" still needs
to import the functionality from "C" it needs (e.g. putting import(C)) in its
NAMESPACE file. These days 'R CMD check' enforces this but some older packages
on CRAN may not have the import() directives and in that case you have no
other option than to "Depend" on "C". (In this case, write to the package
maintainer to alert them about the problem.)
As to indirect dependency on R version I am also not clear.
Georgi
From: R-package-devel [r-package-devel-boun...@r-project.org] on behalf of Hugh
Parsonage [hugh.parson...@gmail.com]
Sent: 24 January 2018 13:44
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Is it ever appropriate (or mandatory) to Suggests: R
(>= version) ?
I believe it is a requirement that if package A imports package B, and
package B lists package C in Depends: then package A must also list
package C in Depends:
A popular stackoverflow answer states this.[1] I can't find any other
source but it makes sense.
What if package B is suggested by package A and package B depends on a
certain version of R? That is if package A *suggests* package B and
package B lists Depends: R (>= ver). In such a case, is it necessary
to list this dependency in Suggests? Certainly endnote 12 of WRE says
it would be necessary if the dependency were for a package, but
doesn't seem to mention similar dependencies on R version. And, as far
as I can see, no package on CRAN lists R in Suggests, so it would to
be non-standard if not prohibited.
S <- available.packages()
S[grepl("(?https://stackoverflow.com/a/8638902/1664978
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Working with R-devel
On Linux you can trace all the getenv calls with ltrace. It only
works on ELF files, not sh scripts:
% R CMD ltrace -e getenv `R RHOME`/bin/*/R
libR.so->getenv("R_HOME")
= "/home/R/R-3.4.3/lib64/R"
libR.so->getenv("R_TRANSLATIONS")
= nil
libR.so->getenv("R_PLATFORM")
= "x86_64-pc-linux-gnu"
libR.so->getenv("R_PAPERSIZE")
= "letter"
libR.so->getenv("R_PAPERSIZE")
= "letter"
libR.so->getenv("R_PRINTCMD")
= "lpr"
libR.so->getenv("R_RD4PDF")
= "times,hyper"
...
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Wed, Jan 24, 2018 at 6:11 AM, Dirk Eddelbuettel wrote:
>
> On 24 January 2018 at 07:03, luke-tier...@uiowa.edu wrote:
> | If you are picking up an R 3.4.x that is trying to load a package
> | built by R-devel you should also see a warning that the package was
> | built under R version 3.5.0
>
> Yes, I am of course very aware of the issue.
>
> But we had to separate out R-release and R-devel for years, and so I did. I
> had separate libPaths (or, at least, leading component) for R-devel because
> of that.
>
> | If you are not, then you could be picking up an older R-devel from
> | before the internals change. Probably more likely, the Rcpp being
> | loaded at that point was built by 3.4.x, which would suggest library
> | path settings are messed up at that point, but not clear why. [It
> | might be possible and useful to provide more information about the
> | broken pieces in the error message but I won't have time to look any
> | time soon.]
> |
> | At the moment when it matters I usually use
> |
> | env R_LIBS= R CMD check ...
> |
> | for checks under R_devel
>
> It was the R_LIBS_USER (which used to work) to R_LIBS change that got plus
> the fact that my R-devel was picking up my R-release check.Renviron. The
> hint
> from Martin got rid of that.
>
> Sometimes I wonder if we should have an extra-verbose mode that picks up
> EVERY single Sys.getenv() and alike to make it easier to trace this. But
> run-time cost of the check is probably unattractive.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Working with R-devel
On 24 January 2018 at 07:55, William Dunlap wrote:
| On Linux you can trace all the getenv calls with ltrace. It only
| works on ELF files, not sh scripts:
|
| % R CMD ltrace -e getenv `R RHOME`/bin/*/R
| libR.so->getenv("R_HOME")
|= "/home/R/R-3.4.3/lib64/R"
| libR.so->getenv("R_TRANSLATIONS")
|= nil
| libR.so->getenv("R_PLATFORM")
|= "x86_64-pc-linux-gnu"
| libR.so->getenv("R_PAPERSIZE")
| = "letter"
| libR.so->getenv("R_PAPERSIZE")
| = "letter"
| libR.so->getenv("R_PRINTCMD")
|= "lpr"
| libR.so->getenv("R_RD4PDF")
|= "times,hyper"
| ...
A+ suggestion.
I was thinking about strace and filtering that, but was unaware of its ltrace
trick. Very nice---thanks, Bill!
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] new package? - Sports data from transfermarkt.com using rvest
Hey, I am not a laywer but their terms are quite explicitly prohibiting redistribution of their data without written consent. Now you might build a package that does not collect, store and redistributes the data but only allows to access the data provided there 'live' via some convenience functions. But I don't really know if that argument actually is valid in any legal sense. To be on the safe side, you probably should contact them. Best, Peter Am 24.01.2018 12:13 nachm. schrieb "Thierry Onkelinx" < thierry.onkel...@inbo.be>: > Dear Daniel, > > First of all you need to make sure that the licence of > transfermarkt.com allows the usage that you have intended. If that is > not clear from their website, then you should contact them rather than > us. > > CRAN has several packages to assists in downloading data from online > sources. But the source has to allow that kind of usage. > > Best regards, > > ir. Thierry Onkelinx > Statisticus / Statistician > > Vlaamse Overheid / Government of Flanders > INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE > AND FOREST > Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance > thierry.onkel...@inbo.be > Havenlaan 88 bus 73, 1000 Brussel > www.inbo.be > > > /// > To call in the statistician after the experiment is done may be no > more than asking him to perform a post-mortem examination: he may be > able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher > The plural of anecdote is not data. ~ Roger Brinner > The combination of some data and an aching desire for an answer does > not ensure that a reasonable answer can be extracted from a given body > of data. ~ John Tukey > > /// > > > > > 2018-01-23 16:27 GMT+01:00 Kehl Dániel : > > Dear List members, > > > > maybe this is not the right place to ask, if that is the case, please > forward me to the right place. > > I developed some functions to download and transform football/soccer > related data from transfermarkt.com. > > There are plans to create my first package based on these functions and > of course develop them and add more later. As far as I know there is no API > to that page, so I am using the rvest package. > > My question is: is this an OK thing to do? Should I contact > transfermarkt.com? My german is not perfect (just like my english), this > is what I've found on thier webpage. Does that mean one can not create a > package related to that page? Or can't crawl at all? Or just not allowed to > sell the data? If it is allowed, can one post the package on CRAN at the > end? > > > > Please if any of you have experience in that or just show me where to > ask, do not hesitate! > > > > LEGAL NOTICE > > © Transfermarkt GmbH & Co. KG 2000-2018 > > > > All rights reserved. > > > > Der Inhalt dieser Website ist urheberrechtlich geschützt. Nachdruck, > Aufnahme in Online-Dienste, Internet und Vervielfältigung auf Datenträger > wie CD-ROM, DVD-ROM usw. dürfen, auch auszugsweise, nur nach vorheriger > schriftlicher Zustimmung durch Transfermarkt erfolgen. Eine kommerzielle > Weitervermarktung des Inhalts ist untersagt. > > > > Transfermarkt haftet nicht für unverlangt eingesandte Inhalte, > Manuskripte und Fotos. Für Inhalte externer Links und fremde Inhalte > übernimmt Transfermarkt keine Verantwortung. > > > > Thank you for all your insights and/or comments, > > > > best regards > > Daniel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dr. KEHL Dániel > > > > adjunktus > > > > > > > > > > > > PÉCSI TUDOMÁNYEGYETEM KÖZGAZDASÁGTUDOMÁNYI KAR > > > > Közgazdaságtan és Ökonometria Intézet > > > > H-7622 Pécs, Rákóczi út 80. | www.ktk.pte.hu > > > > +36 72 501 599/ 23144 | ke...@ktk.pte.hu > > > > > > > > > > > > > > > > > > > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
