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

Stance (or discussion) on src/ directory #320

Open
ctheune opened this Issue Jun 7, 2017 · 154 comments

Comments

Projects
None yet
@ctheune
Copy link

ctheune commented Jun 7, 2017

Is there an official stance on the "src/" directory thing? I'm all for it (and @hynek seems to agree) but I haven't found any discussion or explanation about it from the PyPA. The guide doesn't mention it and the sample project doesn't use it. Even if the stance is "don't use it" (which I would disagree with) then I'd love to see this discussed in the official guide so we can refer to it when people need to make up their mind or argue it.

@ctheune

This comment has been minimized.

Copy link
Author

ctheune commented Jun 7, 2017

@pfmoore

This comment has been minimized.

Copy link
Member

pfmoore commented Jun 7, 2017

I don't think there's a consensus on the best practice, and the packaging guide isn't really intended to cover general development practices, which this is. There's no discussion on testing or documentation, for similar reasons.

@theacodes

This comment has been minimized.

Copy link
Member

theacodes commented Jun 7, 2017

Based on the doc plan in #317, this is actually a good candidate for a discussion topic. I would be willing to accept a PR to add this topic.

@pfmoore

This comment has been minimized.

Copy link
Member

pfmoore commented Jun 7, 2017

Nice, @jonparrott - I hadn't seen that doc plan. Agreed this would make a good discussion topic. Another one I've seen come up in the past is whether to put tests in the package or in a separate test directory.

@theacodes

This comment has been minimized.

Copy link
Member

theacodes commented Jun 7, 2017

@pfmoore for sure, I'd be happy to have that topic as well.

@theacodes

This comment has been minimized.

Copy link
Member

theacodes commented Jun 23, 2017

@ctheune if you or @hynek are interested in contributing this topic, I would love to review and merge it. :)

@pfmoore

This comment has been minimized.

Copy link
Member

pfmoore commented Jun 23, 2017

I'd also be interested in reviewing this. I tried a layout using src just recently and found there were some things that were fiddly to get right (coverage was one), so I have a test case I could use to see how the recommendations work in practice :-)

@hynek

This comment has been minimized.

Copy link

hynek commented Jun 23, 2017

Have you seen https://hynek.me/articles/testing-packaging/ Paul? I hoped to de-fiddle the process there...

@pfmoore

This comment has been minimized.

Copy link
Member

pfmoore commented Jun 23, 2017

@hynek Yes I have. The problem I had was not with combining coverage, but with the basic coverage output from a single tox environment. It's possible it was just lack of familiarity with running coverage under tox, but from what I recall the output had some rather badly nested directories, when I was after filenames relative to src (so mypkg/__init__.py). I backed out the implementation of coverage, so I don't have it to hand at the moment, but could reimplement it if needed.

@ctheune

This comment has been minimized.

Copy link
Author

ctheune commented Jun 28, 2017

Thanks for picking up that topic - happy to contribute although I can't promise to be very responsive at times (busy company and small child make my FLOSS contributions a bit spotty at the moment).

I haven't run into the coverage issue before - I usually have both a tox and non-tox pytest setup and ensure my coverage is right in the basic setup. I see the need for checking coverage of Python--version-specific code paths, though.

What's the next step for contributing here?

@theacodes

This comment has been minimized.

Copy link
Member

theacodes commented Jun 28, 2017

@pradyunsg

This comment has been minimized.

Copy link
Member

pradyunsg commented Aug 25, 2017

Is anyone working on this right now?

@theacodes

This comment has been minimized.

Copy link
Member

theacodes commented Aug 25, 2017

@ofek

This comment has been minimized.

Copy link

ofek commented Sep 5, 2017

I really, really dislike this structure. It makes things a bit more complicated than necessary imo. Newcomers should be considered here.

@hynek

This comment has been minimized.

Copy link

hynek commented Sep 9, 2017

@ofek

This comment has been minimized.

Copy link

ofek commented Sep 9, 2017

@hynek More explicit is worse for beginners when they could rather have a simple packages=find_packages() 🙂

@hynek

This comment has been minimized.

Copy link

hynek commented Sep 10, 2017

@theacodes

This comment has been minimized.

Copy link
Member

theacodes commented Sep 12, 2017

For beginners we'll likely have a new tutorial using flit as a starting point. Setuptools-style packaging would likely fall under guides, and a separate guide/discussion can be created around this topic.

@hynek

This comment has been minimized.

Copy link

hynek commented Sep 15, 2017

I'm not sure whether pushing for flit is the right way as long as it precludes the usage of tox.

@theacodes

This comment has been minimized.

Copy link
Member

theacodes commented Sep 15, 2017

I'm not sure whether pushing for flit is the right way as long as it precludes the usage of tox.

tox does a lot of weird stuff, but how does flit preclude using tox?

@hynek

This comment has been minimized.

Copy link

hynek commented Sep 15, 2017

@theacodes

This comment has been minimized.

Copy link
Member

theacodes commented Sep 15, 2017

I think you can turn that off or use a different install command (though the later affects deps as well).

I definitely plan to try out flit significantly before writing the experimental tutorial and gathering feedback before considering making the experimental tutorial official. So this is really useful.

Also, shameless plug that tox isn't the only option.

@obestwalter

This comment has been minimized.

Copy link

obestwalter commented Sep 15, 2017

but last time I checked tox needed a setup.py to work

No.

[tox]
skipsdist = True

[...]

... and you're golden.

@obestwalter

This comment has been minimized.

Copy link

obestwalter commented Sep 15, 2017

@jonparrott interesting - quite new project also - how come you thought nox is needed? What's missing from tox? I am always interested in seeing how we can improve tox and maybe join forces, if you like open an issue or write on the list.

@theacodes

This comment has been minimized.

Copy link
Member

theacodes commented Sep 15, 2017

@obestwalter mostly just frustrated with using ini files. :)

@obestwalter

This comment has been minimized.

Copy link

obestwalter commented Sep 15, 2017

That's what I thought :D - also see tox-dev/tox#600 - sorry for hijacking this - I am quiete now ...

@theacodes

This comment has been minimized.

Copy link
Member

theacodes commented Sep 15, 2017

@obestwalter cool. :) I think there's room for both. If you ever want to chat about it feel free to reach out. :)

@E3V3A

This comment has been minimized.

Copy link

E3V3A commented Nov 23, 2018

Found this similar discussion, when trying to understand why so many of the packaging-problems issues had not been closed... 🤔
pypa/packaging-problems#1

@ncoghlan

This comment has been minimized.

Copy link
Member

ncoghlan commented Nov 24, 2018

@E3V3A @takluyver is being overly modest, since flit init + flit publish already makes publishing (almost) as simple as you'd like it to be: https://flit.readthedocs.io/en/latest/

The "almost" comes from the fact that pip itself is unlikely to ever become a publishing tool due to the fact that pip operates under much stricter bootstrapping requirements that publication tools mostly no longer face, as well as the long list of problems created by setuptools tightly coupling itself to a specific installer by way of implementation defined data formats.

Disentangling ourselves from the consequences of the latter flaw has literally taken years, and we're only just now reaching a point where it may be viable for flit to replace setuptools as our default build system recommendation.

@takluyver

This comment has been minimized.

Copy link
Member

takluyver commented Nov 25, 2018

I can definitely see how the packaging experience could be simpler than Flit if the tool was restricted to a more specific use case. But at the other end, Flit's limitations still concern me - not because I want everyone to use it, but because people will use it and hit the limits, and then they have to rewrite their packaging to use another tool.

In any case, this issue is about the src/ question, even if that has stalled a bit. If we have other ideas for general ecosystem improvements, let's bring them up on distutils-sig, or on the packaging-problems repo, so that this thread can stay focused.

@takluyver

This comment has been minimized.

Copy link
Member

takluyver commented Nov 25, 2018

Trying to move the discussion forwards again:

Some people want to ensure they're testing the installed version. While I think the most common need for this is actually a shortcoming of packaging tools, there is a definite need for this where packages have a build step - you'd never want to totally rely on inplace builds. Other people want to ensure they're testing the local version, and this too seems like an important convenience for getting quick feedback while developing.

Both testing use cases can, I think, be addressed by including tests inside the package. Then whichever package location you can import is the one you will test. It also has a nice benefit for packages which depend crucially on the underlying platform & libraries, like numpy: distributing the tests with the package allows many more users to run the tests and report obscure bugs. So I think tests-in-package should be the default recommendation (but keep reading). I say that despite being a habitual tests-outside-package developer myself.

The one use case that absolutely requires src/ layout is testing the installed package with tests-outside-package. So adopting tests-in-package as the default would reduce the need for src/ layout. However:

  • With tests-in-package, src/ layout makes testing the installed package easier, whereas non-src makes testing the local code easier. However, I think there are good arguments here for src/:
    • It's easier to write/extend tools to make testing code in ./src easy than to exclude the local copy from tools that would otherwise see it.
    • The failure mode is more likely to be an error like 'couldn't find tests', rather than doing something that you didn't expect.
  • At least one use case requires tests-outside-package: if your tests require a large amount of data that can't be generated by the tests, and you don't want to make everyone installing your package download that data. These cases would require a src/ layout to be able to use those tests on an installed copy of the package.

I guess this is a rambling way of saying that I think src/ layout should probably be recommended. So my habitual development style is 0/2 in this comment. ;-)

@pfmoore

This comment has been minimized.

Copy link
Member

pfmoore commented Nov 26, 2018

Thanks. That's a nice summary. This sounds like we're reaching consensus on the src layout being the right recommendation. However, I do think that the arguments in favour of the non-src layout still have some merit. So what I propose is the following recommendation from PyPA:

  1. The src layout is recommended for all projects
  2. The non-src layout is an allowed, but discouraged, alternative. Particular cases where it is considered acceptable are:
    a) Packages that have used the non-src layout for historical reasons.
    b) New projects that are packaging an existing set of scripts that have been developed in a non-src layout1.
  3. Projects using a non-src layout are strongly encouraged (but not required2) to consider changing to a src layout.

To implement this, we need to take the following steps:

  1. Write up the recommendation in the PUG.
  2. Include a discussion in the PUG of how to set up tools and workflows to handle the src layout (the comments made in this discussion that it's not always obvious - escpecially for new users - how to set up a src layout are valid, and should be addressed in the guide).
  3. Modify the PyPA sample project to use the src layout.

Possibly also include a discussion of the reasons for the src layout in the PUG. But we should keep this simple - it would be intended as clarification of why the src layout is the right choice, not as an invitation for readers to make their own judgement.

Development tools should ensure that they support the src layout cleanly - they can obviously also support the non-src layout, but we should be clear that in order to be recommended in the PyPA guidelines, a tool must be capable of supporting the src layout. That's not to say that the src layout must be the default behaviour (setuptools' find_packages default behaviour isn't something that we can expect to change, for example) but nor is it acceptable for a tool to need extensive configuration to handle the src layout. Ideally, new tools should default to the src layout.

Flit will obviously need to make its own decisions on timescales and transition to the src layout. I deliberately didn't include an exclusion above for "projects using flit", as that's something that should be handled by flit's own transition and conformance process.

Comments? Volunteers?

1 Considerations for code layout for standalone scripts are very different than those for packaged libraries, and the recommendations here should not be assumed to apply to locally-developed standalone scripts. So the exclusion here is intended to allow for a transition process as a project adopts a more formalised packaging strategy.
2 These are recommendations, not rules, so it's not as if we can mandate anything here, of course 😄

@certik

This comment has been minimized.

Copy link

certik commented Nov 27, 2018

Who in the Python community is the authority to decide this?

I disagree with the recommendation for the reasons I stated above (I am not going to repeat them here). I feel there might be a silent significant minority (or perhaps a majority?) of users who don't like the src approach. At this point, what should be the method to arrive at an agreement?

One method is to simply vote by people with merge access to this repository. Then I think it's clear that the src approach wins. But is that what most Python developers actually prefer?

P.S., @pfmoore here (#560) is a PR that tries to evaluate the pros and cons of the various approaches, if you have any comments to it, please let me know.

@theacodes

This comment has been minimized.

Copy link
Member

theacodes commented Nov 27, 2018

@certik

This comment has been minimized.

Copy link

certik commented Nov 27, 2018

@theacodes I agree. I tried to do 1. and 2. in #560, unless I misunderstand your comments. #560 is actually a superset of 2.: it shows how to configure tools to work with the "src" layout, but it also shows how to configure tools to work with the "non-src" layout. So to fullfill 2., the "non-src" part can be removed. 3. and 4. can then be done by the proponents of the "src" approach.

@pfmoore

This comment has been minimized.

Copy link
Member

pfmoore commented Nov 27, 2018

Who in the Python community is the authority to decide this?

Probably two people - @theacodes, as primary maintainer of the PUG, and (maybe) myself, as BDFL-delegate for packaging. Personally, I'm not particularly keen on deciding this by mandate - I'd prefer to get consensus from interested parties. But consensus in this case is never going to mean "everyone agrees", so we need to judge when enough people are OK with the decision.

Conversely, I don't think that a vote is the right thing to do here. It would be impossible to get a truly representative cross-section of the community to vote, so the result of any vote would always be subject to criticism on the grounds of "not being a fair result".

I feel there might be a silent significant minority (or perhaps a majority?) of users who don't like the src approach.

Quite possibly. But unless they are motivated to speak up and argue against the src layout here, it's difficult to see how we do anything practical with that suspicion. We can't be forever paralyzed from making a recommendation simply because someone "might" not like it. And to reiterate, these are only recommendations - people can ignore them if they are that concerned (although if the PyPA recommendation is universally ignored by actual projects, then clearly we have failed to build any sort of consensus, so that's not something we want to happen).

At this point, what should be the method to arrive at an agreement?

I've read the various arguments here, and so far the people arguing in favour of src based layouts outnumber those arguing against. At some point we have to choose, and accept that not everyone will be happy with that decision.

@theacodes I'm not sure it's helpful to have yet another discussion page for this. The whole subject has been discussed to death by now, both here and on @certik's page.

For me the compelling point was made in @takluyver's recent post - "The one use case that absolutely requires src/ layout is testing the installed package with tests-outside-package". IMO, the proponents of the non-src layout need to address that, otherwise everything comes down to subjective views (and we've heard a lot of them, on both sides).

Given that the non-src layout "wins by default"1, I think that the next stage is going direct to what is essentially @theacodes' step (2) - someone in favour of the src approach should write a PR updating the PUG to reflect that approach. We can then review that PR and decide whether or not to accept it.

1 Are the proponents of "non-src" in agreement with that? If not, then what they need to do is to create an alternative PR that demonstrates the changes they would like to see, to change the current guides from simply "showing but not recommending" the non-src layout, to formally recommending it.

@pfmoore

This comment has been minimized.

Copy link
Member

pfmoore commented Nov 27, 2018

Adding my personal views as a separate comment, so that I don't muddy the waters over the process-related points I made in the previous comment,

  1. I don't personally care very much what the "official recommendation" is. I'll likely continue doing what I do at the moment: for new projects, start with a non-src layout, and move to a src layout "when the project gets big enough" (which I'll judge subjectively, but will likely be sooner rather than later). I'd like the official recommendation to support my choice, but if it doesn't, I won't change my approach.
  2. For existing projects that I maintain, I'll do what everyone does, and follow the project standards. If I have sufficient influence, I'll argue for the src layout. Having that be the PyPA recommendation will make that argument easier to make, but that's all.
  3. (The big problem for me) I'd really like to switch to using flit for at least some of my new projects. But I won't do that unless flit supports the src layout, because I don't want to get "locked in" to the non-src layout. So what layout flit chooses matters a lot to me - and flit has tied its choice to the PyPA recommendation. But if the PyPA (and flit) goes for non-src, I'll simply not use flit, so while that will be disappointing for me it's not the end of the world.

Please take this as it's intended - a statement of my personal views, and a data point. It's not intended as a threat, or an attempt to persuade anyone.

My ideal solution would actually be for PyPA to recommend src but allow non-src as a valid alternative (as I proposed previously) and for flit to allow both. But I don't see that (in particular the flit part) happening, unfortunately :-(

@TiemenSch

This comment has been minimized.

Copy link

TiemenSch commented Nov 27, 2018

I think the frustrating thing in the current landscape is that there isn't a easy-to-use pyproject.toml alternative such as flit that supports src/. enscons is named here and there, but I can't find any decent documentation on how to use it. As far as PR's go for flit, I already forked it to support a module_root (or insert any appropriate name) config option some time ago, which would make switching between layouts rather easy, right from the .toml. A tool should be flexible where it comfortably can, but with highly recommended defaults. The alternative (either one) is easily enough explained in the docs or warnings/feedback. But I'm reiterating myself.

As flit changes when the recommendation would, a fallback option to non-src/ would probably have to be in place for handling deprecation anyway.

It may even be the best roadmap to encourage people to change to a recommendation for /src.

  1. Ditch setup.py for flit+pyproject.toml (finally!).
  2. Get a friendly /src recommendation when you use the tool with non-src/.
  3. Switch when ready (or to silence the warning for once and for all).

That way flit can steer people to the PyPA recommended way without frustrating roughly half the current Python packages in this world.

@lithammer

This comment has been minimized.

Copy link

lithammer commented Nov 27, 2018

I think the frustrating thing in the current landscape is that there isn't a easy-to-use pyproject.toml alternative such as flit that supports src/.

As far as I know Poetry (I'm surprised it haven't been mentioned yet) supports this.

$ poetry new --src example
Created package example in example
$ tree example
example
├── README.rst
├── pyproject.toml
├── src
│   └── example
│       └── __init__.py
└── tests
    ├── __init__.py
    └── test_example.py

3 directories, 5 files
@TiemenSch

This comment has been minimized.

Copy link

TiemenSch commented Nov 27, 2018

As far as I know Poetry (I'm surprised it haven't been mentioned yet) supports this.

Since it's not just a packaging tool (it's a complete dependency manager with tons of implications that come with it).

@certik

This comment has been minimized.

Copy link

certik commented Nov 27, 2018

@pfmoore regarding your point:

"The one use case that absolutely requires src/ layout is testing the installed package with tests-outside-package". IMO, the proponents of the non-src layout need to address that, otherwise everything comes down to subjective views (and we've heard a lot of them, on both sides).

I've addressed that here:

https://github.com/pypa/python-packaging-user-guide/pull/560/files#diff-1bd44ab433f0066ca5cbcb4ef56d694bR115

By installing the package and running pytest, one will run the local version of flit. One has to remove the flit directory with rm -r flit to test the installed version.

First of all, I am the proponent of non-src, tests included with the package, so this is not an issue for me. And that is what I recommend.

However, if you really insist on using the non-src, tests outside, then the workflow that I am suggesting is that you test the installed version on a CI, and there it's not a problem to remove the flit directory. And you test the uninstalled package locally. If you really wanted to test the installed package locally, then there are 3 options:

  • remove the flit directory,
  • move the tests to some temporary directory and execute from there
  • improve tooling, such as pytest to ignore the uninstalled flit directory when executing tests

@pfmoore please let me know if this addresses the issue.

@certik

This comment has been minimized.

Copy link

certik commented Nov 27, 2018

Given that the discussion is heading towards a recommendation of using src, I ask the proponents of the src layout to do one thing:

Can you please propose some ideas how to improve the tooling so that one can develop the src based package locally without installing it?

Here is an example how to develop a src package currently:

https://github.com/pypa/python-packaging-user-guide/blob/a358dd74ae67dbf641dcebbbd50a91b084994389/source/guides/package-development.rst#tests-separate-1

And the big Cons is that one cannot import the package locally. The only clean way, currently, is to first create some environment and then pollute it with pip install -e ..

That means that one will have an environment with a development version of the package, causing possible issues down the road when the environment is used for another purpose.

Are there other ways around this? Or does the src layout mean that one cannot develop (test) the package locally anymore, one always requires an environment and pip install -e .?

@Juanlu001

This comment has been minimized.

Copy link

Juanlu001 commented Nov 27, 2018

When I want to skip the pip install -e (for example, in systems without pip) I do PYTHONPATH=$(pwd)/src python3 -m pytest .... Would that work for you @certik ?

@pfmoore

This comment has been minimized.

Copy link
Member

pfmoore commented Nov 27, 2018

@certik - There's no way we should get involved in the "tests inside the package vs tests outside" debate here. FWIW, I favour tests outside, but unless we want to make this debate even more intractable and add that question to the mix, I believe we have to allow both tests inside and tests outside when recommending a layout.

I've addressed that here:

I don't really see that you have. I'm not at all clear what the discussion you linked to proves.

Only being able to run tests on CI is not an acceptable solution, IMO. Nor is moving the tests. I'm not quite sure what you mean by "removing the flit directory", but in general, removing files or directories in order to run tests is not an acceptable solution (to me, at least - which is what you asked).

We're just revisiting the same old arguments here. I don't think anyone is saying anything new any more. I'm pretty burned out with this argument, and as I noted above I no longer think it will affect my personal workflow whatever the outcome (apart from possibly indirectly, through what flit ends up doing). At this point, I'm going to stop responding to attempts to persuade me to switch my support from src to non-src unless someone comes up with something genuinely new to add to the discussion.

I've not counted (I don't want this to be a numbers question) but is anyone other than @certik who is involved in this discussion still in favour of non-src over src? @takluyver I appreciate you're more "coming to accept the way things seem to be going" rather than particularly in support of src, and I suspect there are some people who are more or less indifferent - but does anyone else actively prefer non-src over src? And if there are, do they have anything new to add that hasn't been said already?

@pfmoore

This comment has been minimized.

Copy link
Member

pfmoore commented Nov 27, 2018

Can you please propose some ideas how to improve the tooling so that one can develop the src based package locally without installing it?

Fair question. If you don't want to use editable installs, I'd set $PYTHONPATH to the src directory. I'm not aware of any issues with tooling, though, so beyond that I don't know what you mean.

@theacodes

This comment has been minimized.

Copy link
Member

theacodes commented Nov 27, 2018

@theacodes I'm not sure it's helpful to have yet another discussion page for this. The whole subject has been discussed to death by now, both here and on @certik's page.

@certik's PR adds this as a guide, which is good and part of my proposal, but it alone I think is insufficient. A discussion is a specific page archetype we have here that's intended to compare and contrast two or more options. Take a look at some of the existing (although anaemic) discussion pages:

  1. https://packaging.python.org/discussions/install-requires-vs-requirements/
  2. https://packaging.python.org/discussions/pip-vs-easy-install/

Have both a discussion page on src vs non-src and a guide helps us remain relatively neutral. It also helps if/when we want to switch to making src the preferred method - the pros, cons, and reasons why are well captured in the public documentation which means less pitchforks pointed in my particular direction.

@certik

This comment has been minimized.

Copy link

certik commented Nov 27, 2018

@Juanlu001 thank you! It turns out neither flake8 nor matplotlib actually work this way, because they rely on some magic in setup.py that only works when you install the package. However, the Pillow package works this way. I have updated the document, here is an example how to develop a src package Pillow locally without installing it:

https://github.com/pypa/python-packaging-user-guide/blob/c1d403329929b02d354b582d2def867186a18fe7/source/guides/package-development.rst#prepare-once-5

And it works. Furthermore, as I also mention in the document, the tooling, such as pytest, can be improved to have a new argument, say, --src, that will automatically do the PYTHONPATH=src part, so then this:

PYTHONPATH=src pytest -k test_image_rotate.py

will change to this:

pytest --src -k test_image_rotate.py

@pfmoore this is what I mean by "improving the tooling". @pfmoore I am not trying to persuade anyone, I am simply trying to constructively find a solution to this debate by carefully and as objectively as possible to answer all the common questions about Pros and Cons that people have about all the approaches in #560, with detailed examples how to actually do what people want. I encourage you to read the document I created, and if you have any questions about it (as it seems), to please respond at #560, not here.

@certik

This comment has been minimized.

Copy link

certik commented Nov 27, 2018

@theacodes I agree with the direction of your comment. I have a question about the new "discussion" document. If you look at the Pros and Cons part of #560, it seems they contain a lot of what you have in mind for the "discussion" document? It seems they would have to be rewritten into a form of the examples 1. and 2. (in your comment), and perhaps expanded. Or is that not what you have in mind.

@theacodes

This comment has been minimized.

Copy link
Member

theacodes commented Nov 27, 2018

@ofek

This comment has been minimized.

Copy link

ofek commented Nov 27, 2018

@pfmoore

does anyone else actively prefer non-src over src? And if there are, do they have anything new to add that hasn't been said already?

I do still and I'm sure there are many others who are simply too fatigued to comment 😄

What I plan to do when I have some time is distribute a tiny pytest plugin that more or less does del sys.path[0] at the proper moment during test collection. This ensures tests won't succeed unless an installation is active, either normal or develop.

Users should be required to make an installation choice imo before testing.

@pfmoore

This comment has been minimized.

Copy link
Member

pfmoore commented Nov 27, 2018

A discussion is a specific page archetype we have here

Oh! Sorry, I completely misunderstood you. I thought you were talking about another place on github where we could collect arguments like we've been doing here. My mistake - yes, I like the idea of a discussion page that summarises the trade-offs between the two layouts.

@pfmoore

This comment has been minimized.

Copy link
Member

pfmoore commented Nov 27, 2018

@certik

if you have any questions about it (as it seems), to please respond at #560, not here.

I've added a review over there. Hope it was the sort of thing you were hoping for.

@certik

This comment has been minimized.

Copy link

certik commented Nov 27, 2018

@pfmoore thank you for reading it and providing a feedback. That was precisely what I was hoping for. I'll work on it soon.

@Juanlu001

This comment has been minimized.

Copy link

Juanlu001 commented Jan 8, 2019

Today I got this error and immediately I remembered this issue:

ImportError: Error importing scipy: you cannot import scipy while
        being in scipy source directory; please exit the scipy source
        tree first, and relaunch your python interpreter.

🤦‍♂️

@pradyunsg

This comment has been minimized.

Copy link
Member

pradyunsg commented Jan 13, 2019

#320 (comment)

I'll be working on the discussion topic for this over the next couple of few days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment